OAuth and OpenID Connect as a Service

This page uses the vocabulary defined in the OAuth 2 RFC and the OpenID Connect Specification.


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 applications 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 Identity client in the console, you must specify the scopes they are allowed to request. For improved security, it is recommended you specify the smallest scope possible. In addition, third-party clients should almost never have the full_write scope, as this would allow them to modify any information on behalf of the user.


On the login page, when calling the ReachFive endpoint, you should specify 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 field are detailed in the User profile model. In addition, some endpoints (e.g. which modify data) need other scopes (see the scope documentation).

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.