Enabling OpenID Connect Claims and Prompting User for Consent

ActivID AS can be configured to capture end-user claims and user consent when a given OpenID client requests that ActivID AS authenticates an end user.

The flow is:

1. The user is prompted for their consent when they are authenticated on a client for the first time – the OpenID client application redirects the user to an ActivID IdP logon page.

   If the authenticated user has not signed their consent yet, a consent signing page is displayed.

   

   This consent signing page displays a list of user attributes (such as e-mail address and phone number) as the claims/information to which the client application is requesting access.

   The list of attributes is extracted from ActivID AS based on the scope sent by the OpenID client in the authentication request and defined in the OpenID adapter's parameters (see Configuring Custom Scopes for a Client).

   Note:  

   • The claims already signed by the end user will also be extracted from user's attributes.

   • The final consent displayed to the user for signing contains only the unsigned claims for the requesting OpenID client.

   • If the user clicks Allow to sign their consent, the result is returned to the OpenID client application with success.

   • If the user clicks Cancel to deny access, the result is returned to the OpenID client application with an error (for example, due to insufficient scope).

2. The signed consent is stored by ActivID AS to avoid prompting the user at every authentication.

   The consent is stored in the following user attribute for the end user:

   • Attribute name – OPENID Applications claims

   • Attribute code – ATR_OICST

   

   • Attribute value – list of claims for each client

   The value is of the form:

   <client-1>: <attribute-1>, …,<attribute-n>; … ; <client-n>: <attribute-1>, …,<attribute-n>

   For example: client1: ATR_EMAIL,ATR_MOBILE;client2:ATR_BIRTH,ATR_1124;client3:....

3. ActivID AS checks for this consent when the client calls the token or userinfo endpoints for the user.

4. If the consent is signed, an audit record is generated for auditing.

   

   The audit data contains the end user id, client id, and list of claims signed for consent.

   

5. Once the end user has signed the consent, an access token is generated for the end user. The OpenID client application can use this access token for the UserInfo request.

6. When the OpenID client application sends a request to the OpenID userInfo endpoint, only claims requested during the end-user authentication phase will be returned.

Topics in this section: