Identity Server Token Flow

test

1. Login using the user credentials

This step requires to send the client id and client secret and, if you need to have access to the Opinum Data Hub API, you also need the “datahub-api” scope. Optionally you can add the “offline_access” scope.

You can use either:

  • openidconnect > typically for a web app when users needs to go through a login page like Opinum Data Hub.
  • Resource owner flow > typically for a backend application where there is a dedicated application user or no user interaction at all.

2. Identity server returns the Access Token

If “offline_access” was passed in the scopes, a Refresh Token is also returned.

3. And 4. Interaction loop

This step represent a typical interaction loop between the client application and the Opinum Data Hub API.

5. Expired Access Token

The client application sends a request with an expired Access Token

6. Called Refused

The Opinum Data Hub API refuses the call (HTTP response 401 Unauthorized)

Warning

At this step, if you have not requested the “offline_access” scope, you have to start over at step 1. Otherwise, proceed to next step

7. Request Refresh

The client application sends a request to Identity Server containing the client id, client secret and the refresh token. Note that this step does not require the user credentials anymore as all necessary information is contained in the refresh token

8. Token Refreshed

Identity server returns fresh Access Token and Refresh Token.

After this step, you should go back to Step 3.

Information

One typical use of Refresh Tokens is for mobile applications. The first time you use them, they redirect you to some kind of login page but then, every subsequent use of the app will “re-authenticate” you using a refresh token. This is considered more secure versus storing the user credentials locally on the device.

For backend application, there is very often 1 single dedicated user. The credentials of this user are stored in a configuration file or hard coded directly in the app. So using a Refresh Token or not are both valid approaches. We do not foresee a significant performance difference between the 2 methods. However, asking for a Refresh Token that will not be used after is sub optimal.