OAuth 2.0/OIDC Authentication Flow

Learn more about the Authentication flow for OAuth 2.0 compliant SSO.

Authentication flow for OAuth 2.0 compliant SSO with a third-party authorization server and Reltio Connected Cloud as the resource server will include the following parties:
  • User as Resource Owner
  • Reltio Connected Cloud:
    • Hub (Reltio UI)
    • Reltio OAuth2 service
  • Third-party identity provider (for example, PingFederate, Google Apps, GitHub, ADFS, Okta) as Authorization Server

Typically, the authentication flow includes the following technical interactions:

  1. User attempts to log in to a tenant in Reltio Connected Cloud using Hub.
  2. Hub receives the request (with tenantId) and redirects User to Reltio OAuth2 service.
  3. Reltio OAuth2 service receives an authorization request and automatically redirects User to the associated third-party Authorization Server to get an OAuth code. Using the tenantId provided by Hub, Reltio OAuth2 service chooses an IdP and redirects User to the IdP login page. For example. https://auth-srv.customer.com/as/authorize?client_id=customer.reltio&client_secret=1A2b3C&grant_type=code&scope=profile_name,profile_email&redirect_uri=https://auth.reltio.com/callback&state=ABCD
    Note: The URL is taken from the Login endpoint attribute defined in the configuration.
    Note: In this example, state=ABCD is an internal identifier of the request-it will be used by Authorization Server to tie it to the redirect URL to Reltio OAuth2 service callback page.
  4. Hub gets a token for User by the code received from Reltio OAuth2 service. 6.1 Reltio UI sends an authorization request to Reltio OAuth2 service. For example. https://auth.reltio.com/authorize?grant_type=code&code=<Reltio code>
    • As a result, Reltio OAuth2 service generates an OAuth token request for Authorization Server. For example, https://auth-srv.customer.com/as/authorize?grant_type=authorization_code&code=<code received from Authorization Server in the previous step>
      Note: The URL is taken from the Token endpoint attribute defined in the configuration.
    • Authorization Server should return OAuth access_token / refresh_token in response.
    Note: The length of the access_token / refresh_token must be within 400 characters.
  5. On token validation request, Reltio OAuth2 service needs to associate customer's user with a user in Reltio OAuth2 by email address.
    • Using the token obtained from Authorization Server, Reltio OAuth2 service tries to get user information from IdP. For example, https://auth-srv.customer.com/as/user or https://auth-srv.customer.com/as/checkToken along with OAuth token sent in an appropriate authorization header.
      Note: The URL is taken from User info endpoint attribute defined in the configuration.
    • After Reltio OAuth2 service gets user information, it will try to associate customer's user with a user in Reltio OAuth2 by email. If the user exists, then Reltio platform will validate the roles/privilege against those defined in IdP. If the user does not exist, Reltio will create a new user in Reltio OAuth2 with roles predefined in the configuration of the IdP.
      Note: User mapping Reltio OAuth2-IdP must be unambiguous, it is preferable to use email or user ID.
  6. On refresh token request, Reltio OAuth2 service will use the refresh token directly in IdP.