Securing Exchange of Refresh Token

What does it do?

In general, a Refresh token is obtained along with an Access token and after the access token has expired, the user can perform a new access token request to the authorization server. The refresh token is passed along with this request for validation and is exchanged to obtain the access token. Refer API section to use Access token and Refresh token API’s.

The tokens carry an ACR claim which is of significance here. In mID we have each authenticator mapped to an ACR value. An ACR value of 1 indicates that the refresh token is obtained through a first-factor authentication, and ACR value of 2 indicates that it’s obtained through a second-factor authentication. Refer ACR&AMR values for more information.

Now while ACR=1, the exchanged access tokens cannot procure access to resources until after a further, second-factor authentication is completed, which is not the case with ACR=2. Access tokens obtained through ACR=2 refresh tokens, permit direct access to resources without further authentication.

When this feature is enabled if the refresh token carries ACR=1 a corresponding access token is granted. If ACR=2 then the access token is not granted. The restriction ensures that a second-factor authentication is in play every time for enhanced security.

How to Configure?

To configure this restriction the kobil_secured_refresh scope must be added to the respective client as shown below.

Add the scope to the list of client scopes within the realm

Select the respective client and assign the scope to the Optional Client Scopes section.

Now the feature applies for access requests involving this particular client.