OpenID connect feature has been integrated into the OAuth flow which is discussed in previous sections. This feature enables clients to verify the identity of the end-user based on the authentication performed by an Authorization Server as well as to obtain basic profile information about the end-user in a security token represented as JWT which is referred to as ID token in this context. This is the primary extension that OpenID Connect makes to OAuth.

If a client needs the ID token, either the response_type parameter in the request to Authorization endpoint must include "id_token" or the scope must include "openid". This is how a client can rely on Authorization server for the end-user Authentication.

Possibilities of obtaining an ID Token 

All possible scenarios of obtaining code/token/id_token for different combinations of response_type parameter values that are supported with/without the "openid" in scope within the requests to Authorization and Token endpoints are tabulated below.

 

 

Generating an ID Token

For generating ID token, the following have to be added to the policy configuration:

      A) Under attributes section of the policy configuration, specify the following attributes:

• • Expiry time - (OPTIONAL) Expiry time of the ID token can be provided with the variable name "exp" under the section of policy configuration attributes.
  • Basic user information - (REQUIRED) The end-user information obtained from the resource server should be included as variables in the section of policy configuration attributes, which will then be used by the policy to wrap into additional claims of the ID token. The value of the variable "userID" from among these attributes, which acts as an end-user's identifier, will be used to generate sub claim of the ID token.
  • Issuer - (REQUIRED) Identifier of the issuer i.e the authorization server playing the role of an OpenID provider. This value should be included under the variable name "issuer" in the section of policy configuration attributes. Upon tpolicy execution, this will then be wrapped into iss Claim value in ID Tokens issued by the Issuer. This value shall also be provided in the OpenID discovery URL.
    
    

      B) Following values have to be fed into the flow as context variables using an assign variable policy as shown below.

• • Salt - (REQUIRED) A value that is kept private, not known to the client, which is used in the calculation of the sub claim of ID token. This value must be fed into context variables under the variable name "salt".
  • Private/secret key - (REQUIRED) The key with which the ID token ought to be signed while generation must be fed into context variables. If the algorithm chosen is symmetric, secret key should be included under the variable name "openid_secret_key" or If the algorithm chosen is asymmetric, Private JSON Web Keys and kid value have to be fed into context variables under the variable names "JsonWebKeys" and "kid" respectively using assign variable policy. If the JSON Web Keys are exposed in a URL, specify the URL under the variable name "keysURL" and feed into context variables. The corresponding Public JSON Web Key has to be shared with the client to support the validation of the issued ID token.
    
    

C) Pre-negotiated parameters for the issue of OpenID :

1. Algorithm (to be negotiated while client registration): This value has to be provided among the Client Subscription Properties under the variable name "algorithm". Currently supported algorithms are HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512.
   1. For symmetric algorithms, the ID token will be signed using the secret key fed into context variables prior to the policies.
   2. For asymmetric algorithms, the ID token will be signed using the private key fed into context variables prior to the policies and its corresponding public key will be available in openid discovery information url.
2. Client Authentication method: This section defines a set of Client Authentication methods that can be used by Clients to authenticate to the Authorization Server when using the Token Endpoint.
   The client authentication methods that are currently supported:
   1. client_secret_basic - Clients that have received a client_secret value from the Authorization Server authenticate with the Authorization Server by sending it as one of the request parameters to the token endpoint.
   2. private_key_jwt - Clients that have chosen this method register a public key with the Authorization Server and sign a JWT with its corresponding private key and delivers that JWT during its authentication.
      
      When invoking the token endpoint through a POST method, the request MUST include the following parameters along with grant_type, code, client_id:

• • • client_assertion_type: This must be set to "urn:ietf:params:oauth:client-assertion-type:jwt-bearer".
    • client_assertion: This must contain the encoded assertion JWT.
      The JWT MUST contain the following REQUIRED Claim Values and MAY contain the following OPTIONAL Claim Values:

• • • • iss
        REQUIRED. (Issuer) This claim must contain the client_id of the OAuth Client.

• • • • sub
        REQUIRED. (Subject) This claim must contain the client_id of the OAuth Client.

• • • • aud
        REQUIRED. (Audience) This claim must contain the value that identifies the Authorization Server as an intended audience. It should be the URL of the Authorization Server's Token Endpoint.

• • • • jti
        REQUIRED. JWT ID. A unique identifier for the token. This ensures to prevent reuse of the JWT.

• • • • exp
        REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.

• • • • iat
        OPTIONAL. Time at which the JWT was issued.
  During Client Registration, the client may register any one of the above-mentioned Authentication methods. If no method is registered, the default method is client_secret_basic.

ID Token claims

According to the scenarios mentioned in the table (first section), id_token is generated (based on the request parameters/scope) either at Authorization endpoint or Token endpoint by the respective policies along with code and/or token. The following Claims are present within the id_token issued:

• iss
  REQUIRED. Issuer Identifier for the Issuer of the response.

• sub
  REQUIRED. Subject Identifier. A locally unique identifier for the end-user. This is the value obtained by HS256 hashing of the client's "sector_identifier_uri" or redirect_uri after concatenating it with a "salt" and the end-user's identifier "userID" both provided in the policy configuration.

• aud
  REQUIRED. Audience Identifier. The client_id of the client that the id_token is intended for.

• exp
  REQUIRED. Expiration time on or after which the id_token MUST NOT be accepted for processing.

• iat
  REQUIRED. Time at which the id_token was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.

Additional claims include c_hash and/or at_hash along with some basic user information.

• at_hash: This claim is present only when the access_token is sent along with id_token in the response from Authorization endpoint. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the access token value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's header. This is basically used by the client to validate the access_token.
• c_hash: This claim is present only when the authorization code is sent along with id_token in the response. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the authorization code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's header. This is basically used by the client to validate the authorization code.
• s_hash: State hash value. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the state value, where the hash algorithm used is the hash algorithm used in the alg header parameter of the ID Token's header.

Example 

1. Include "id_token" in response_type parameter in order to obtain ID token from Authorization End Point.
2. Include "openid" in scopes section of client subscription in order to obtain ID token from Token End Point.