Authenticate with the OpenID Authorization Flow

The Authorization Code Flow consists of the following steps:

1. The client prepares an Authentication Request containing the required request parameters:

   • Request with minimum parameters for a confidential client:

     https://server.example.com:8445/idp/domain/authn/login?response_type=code&client_id=spl-api&redirect_uri=http://localhost&scope=openid

   • Request with minimum parameters for a public client:

     https://server.example.com:8445/idp/domain/authn/login?response_type=code&client_id=spl-api&redirect_uri=http://localhost&scope=openid&code_challenge=uSOvC48D8TMh6RgW-36XppMlMgys-6KAE_wEIev9W2g&code_challenge_method=S256

2. The client sends the request to the Authorization Server.

The request can be sent via the HTTP method – either GET or POST.

3. The Authorization Server authenticates the end user:

   1. The ActivID Appliance Server receives an authentication request from the OpenID’s client.

      Where the OpenID client’s configuration parameters are:

      • Channel – CH_SSP
      • Authentication Policy – AT_CUSTPW

   2. The ActivID Appliance server authentication portal displays a login page:

      

   The default the authentication method is determined by the OpenID client’s configuration.

   The end user can also select another authorized authentication method from those available in login page, if they have a valid credential and authenticator authorized for the configured channel.

4. The Authorization Server obtains the end user’s Consent/Authorization.

   Once the end user successfully authenticates with their credential, the ActivID Appliance server will generate an authorization code and prompt the end user to sign a consent before sending the authorization code to redirect URI passed in previous authentication request.

   

Note:  

• The redirect URI sent in the authentication request must match one of URIs defined in OpenID client’s configuration.

• This step can be bypassed if the client has an alternative means of obtaining the end user’s consent. For further information, see Enabling OpenID Connect Claims and Prompting User for Consent.

5. The Authorization Server redirects the end user back to the client (redirect URI) with an authorization code.

   http://localhost/?code=69160835&context=PARAMETER_AUTHENTICATION_TYPE_CODE%3AAT_CUSTPW%3Afalse+LEVEL_OF_ASSURANCE%3A1%3Afalse+

   The format of authorization code is configured in the OpenID client’s configuration:

   

   The supported values are:

   Type	Format	Validity (ms)	Length
   NUM001	Numeric	600000	8
   NUM002	Numeric	180000	20
   ALP001	Alpha	600000	8
   ALP002	Alpha	180000	20
   ANU001	Alpha Numeric	600000	8
   ANU002	Alpha Numeric	180000	20

6. The client sends the code to the token endpoint to obtain an Access Token and ID Token in the response:

   Copy

   Sample request for a confidential client

   POST https://[base-server-url]/{tenant}/authn/token HTTP/1.1Authorization: Bearer RTp7HwAAAWWj8IUbUYXmgm2p2y3d0ZsqhhR+rJtT
    
   grant_type=authorization_code&code=40823936&client_id=spl-api&redirect_uri=http%3A%2F%2Flocalhost

   Where client authentication is required (in the above example, the bearer token is obtained by a client authentication at the token endpoint).

   Copy

   Sample request for a public client

   POST https://[base-server-url]/{tenant}/authn/token HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
    
   grant_type=authorization_code&code=40823936&client_id=spl-api&redirect_uri=http%3A%2F%2Flocalhost &code_verifier=CmUuMpOKy1Y%2FMFmjN2pHxdby17DeQgC8dSWMIiEL%2Bc%2B0Lnp47FphzeB%2B012i6WVTv0A07N3QvcJU9asqr3byfg%3D%3D

   Where the code_verifier corresponds to the code_challenge sent in the previous request to the authentication endpoint. For further information, see Leveraging Proof Key for Code Exchange (PKCE) in the Authorization Code Grant Flow.

   Copy

   Sample response

   HTTP/1.1 200 OK
   Content-Type: application/json;charset=UTF-8
    
   {
      "access_token": "TXsPRQAAAWWj8QFOO51UR7Ow/yCnEZMMP6OMwfg/",
      "id_token": "eyJraWQiOiIxNTM0NDI5MTA0Njg1IiwiYWxnIjoiUlMyNTYifQ.eyJz…Zc3Mq9Q",
      "token_type": "Bearer",
      "expires_in": 3599
   }

7. The client validates the tokens and retrieves the end user’s Subject Identifier.

   The client can verify the signature of the id_token with the ActivID Appliance server’s signing certificate retrieved from the jwks endpoint:

   1. Once the signature is verified, the client can parse the id_token content:

      Copy

      {
        "at_hash": "wcvmNj4esm3….", 
        "sub": "test01",
        "aud": "spl-api",
        "iss": "https://server.example.com:8445/idp/domain/authn/token",
        "exp": 1536057405,
        "iat": 1536053805,
        “acr”: 2
      }

   2. Once the client validates the ID Token, it can use the end user’s access token to access the protected resources during a validity period.