- Human-readable information
- Pleo specific information
- Technical information
Registration Data
Human-Readable Information
Human-readable information represents the following to the end-users:- Branding of the client
- Link to the home page of the application or a page announcing the integration of the application with Pleo
- Legal Policy documentation
Pleo Specific Information
The following table lists the parameters that are specific to integration of your client with Pleo:Technical Information
Technical information is used internally in OAuth 2.0 protocol to implement the redirection between the Pleo authentication server and the client.Client Credentials
After completing registration, you would receive a set of credentials for your client:- Client Identifier: This is a unique identifier that makes your client easily identifiable from others. In addition, it allows Pleo to present the branding of your client to end-users when they are asked to authenticate their identity while trying to access the Pleo data. Client identifier is not a confidential information and is visible to anyone attempting to connect your client with Pleo using OAuth 2.0.
-
Client Secret: Requests from the client are authenticated using the Client Secret, most notably, during access token request. As the name suggests, this information is confidential and you must store this securely.
- Client secret must never be stored on or exposed to a device to which the end user has direct access. For example, it cannot be embedded in the code of the application that runs on users’ devices or transferred over network to a user’s device.
- Client secret may only be stored and used on a secured server component of your client from where it cannot be extracted easily.
Client Registration Example
A hypothetical client can be registered using the following parameters:
After registration, partners receives a set of client credentials.
These values are explained in the Example section of Implementing OAuth 2.0 Reference Documentation.
Redirect URIs
Redirect URI indicates the location where the users are redirected after successful authentication. Hence, in the context of Pleo integration with your client, after the Pleo Authorisation Server authenticates your client, the users are redirected to the specific URI. HTTP redirections are crucial in OAuth 2.0 protocol flow using authorisation code grant. The client must implement a redirection endpoint, also known as “OAuth 2.0 callback”. This endpoint must be secured by Transport Layer Security (TLS) and must be hosted on a public domain (hence, accessible to all users on the internet). When registering your client, you must provide this redirection URL in the technical information. HTTP is allowed for local development Use of HTTPS is often inconvenient in local development environment. Therefore, there is an exception for “loopback” or “localhost” redirect URIs, which can use the unencrypted HTTP protocol. Specifically, these hosts can usehttp scheme in redirect URIs:
localhostloopback interface127.0.0.1IPv4 loopback interface, recommended[::1]IPv6 loopback interface
localhost host name is supported. Aliases such as myclient.localhost or myclient.local would not be accepted.
Multiple Redirect URIs
If you intend to support multiple URLs for redirection endpoints, you must provided as a list of registered redirect URIs.
Often, a client allocates resources of their customers in subdomains (or sub-paths). For example: an application might host Alice’s resources at alice.client.example, Bob’s resources at bob.client.example. Some early implementations of OAuth 2.0 offered this functionality, but later it is diagnosed to be vulnerable to a certain class of attacks on the OAuth 2.0 protocol.
If your client uses wildcards, we recommended using the state parameter to save the location your users must be redirected to after completing the OAuth 2.0 flow. In this way, a single redirect endpoint can dispatch users’ browsers to different destinations.