OAuth and OpenID Connect as a Service

This page uses the vocabulary defined in the OAuth 2 RFC and the OpenID Connect Specification. Please refer to those for more information.


There are two kinds of Identity client applications: first-party and third-party.

First-party clients are applications that are directly controlled by the entity handling the data (the account owner). When they request the scope they need to read and modify the data, the end-user is not asked for confirmation of the scopes.

Third-party clients are application controlled by a partner or any other entity. When they request a scope (typically to read data), the user must confirm they allow the application to access the data, before the account owner acknowledges their authorization.

When configuring an Identiy client in the console, you must specify the scopes they are allowed to request. It is recommended you specify the smallest scope possible, as this improves security. In addition, third-party clients should almost never have the full_write scope, as this would allow them to modify all informations on behalf of the user.


On the login page, when calling the ReachFive endpoint, you should request the scopes you need. When a client application tries to access some service on behalf of the end-user, it can authorize itself using the access token, and the scopes in the access token will be checked.

When reading from the ReachFive endpoints, only the data available to your scopes will be returned. The scopes needed for each fields are detailed on the data model. In addition, some endpoints (e.g. that modifies data) needs other scopes (see the scope docunentation).

The access token can also be used by a third party client to authorize itself on a first-party client application. The first-party client can access the scopes contained in the access token using the introspection endpoint, and check that the proper scopes (typically custom scopes) are set.