OpenID Connect

Authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User. It also describes the security and privacy considerations for using OpenID Connect.

OpenID Connect has become the leading standard for single sign-on and identity provision on the Internet. Its formula for success: simple JSON-based identity tokens (JWT), delivered via OAuth 2.0 flows designed for web, browser-based and native / mobile applications.

Overview:

The OpenID Connect protocol, in abstract, follows the following steps.

1. The RP (Client) sends a request to the OpenID Provider (OP).

2. The OP authenticates the End-User and obtains authorization.

3. The OP responds with an ID Token and usually an Access Token.

4. The RP can send a request with the Access Token to the User Info Endpoint.

5. The User Info Endpoint returns Claims about the End-User.

ID Token:

The ID token resembles the concept of an identity card, in a standard JWT format, signed by the OpenID Provider (OP). To obtain one the client needs to send the user to their OP with an authentication request.

The following Claims are used within the ID Token for all OAuth 2.0 flows used by OpenID Connect:

{
   "iss": "https://server.example.com", // req:The iss value is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.

   "sub": "24400320", // req: A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. 

   "aud": "s6BhdRkqt3", // req:Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value

   "nonce": "n-0S6_WzA2Mj", // req:String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. Authorization Servers SHOULD perform no other processing on nonce values used.

   **"exp": 1311281970**, // req:Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. 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.

   "iat": 1311280970,// req:Time at which the JWT 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

   "auth_time": 1311280969,// req/opt: when the End-User authentication occurred. 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. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
   "acr": "urn:mace:incommon:iap:silver" //opt
  }

ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. If the ID Token is encrypted, it MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.

ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields. Instead, references to keys used are communicated in advance using Discovery and Registration parameters,

• Encoded as a JSON Web Token (JWT).

• The claims about the subject are packaged in a simple JSON object.

• Digitally signed typically with the provider's private RSA key or a shared secret (HMAC) issued to the client during registration.

• Is URL-safe.

Example ID Token Encode Format

eyJhbGciOiJSUzI1NiIsImtpZCI6ImQ2M2ExOGU0LWI1NzMtNGJlNy1iYzM2LTNiM2RiMTUzNWExMiJ9.eyJzaWQiOiIwZDBmMjE4OC0wYWU1LTQzN2QtOTk5MC1jM2MzMGQ1YTRkODUiLCJzdWIiOiJhOGUzODZhMS0wMTMyLTRmOTktYjhmNS0zYWNjMTM1YWFhMmYiLCJhdWQiOiJjMTdjNmYyYS00NzI5LTRjZjMtODk2My03NmZiM2ZjMGNjNDkiLCJpYXQiOjE1NDkwMTM4NTMsImF1dGhfdGltZSI6MTU0OTAxMzg1MywiaXNzIjoiaHR0cHM6Ly9uaWdodGx5YnVpbGQuY2lkYWFzLmRlIiwianRpIjoiZTg4MjkwMzItYTU3MC00MTA2LTgwZjYtZGFmZmQ3OWIyZGRkIiwic2NvcGVzIjpbXSwicm9sZXMiOlsiVVNFUiJdLCJncm91cHMiOlt7InJvbGVzIjpbIlNFQ09OREFSWV9BRE1JTiJdLCJncm91cElkIjoiQ0lEQUFTX0FETUlOUyIsImlkIjoiMDEwMjdiMzctNjg4Zi00ODdjLWIxNjktM2I3ZmFlMzhiM2IzIn1dLCJleHAiOjE1NDkxMDAyNTN9.X18yHYSvpkEiakxZ3t5ogoD-BK4XG1UR83c7mRlH5nsC1Byc-cvPEJiS-dHAwzVVgOl1Hzg60V_9oSzuZ0Ve07CZfYq73ogXzSatjVaa7INUTbRvopGhuZ5VUwFo0OSSgKPq4UiDB-EAfaIqM-Z63Fj1COxChi_OmfYeo-mpwbo

The OAuth 2.0 protocol flows through to obtain an ID Token before that how openID Connect related to OAuth 2.0?

OAuth 2.0 is a framework for obtaining access tokens for protected resources such as web APIs. OpenID Connect utilizes the OAuth 2.0 semantics and flows to allow clients (relying parties) to access the user's identity, encoded in a JSON Web Token (JWT) called ID token. The access token facilitates retrieval of consented profile details (called claims or attributes) from the UserInfo endpoint of the OpenID provider.

OpenID Connect Authentication Flow:

OpenID Connect performs authentication to log in the End-User or to determine that the End-User is already logged in. OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it. For this reason, the Client is called Relying Party (RP) in this case.

The Authentication result is returned in an ID Token, as defined in Section 2. It has Claims expressing such information as the Issuer, the Subject Identifier, when the authentication expires, etc.

Authentication can follow one of three paths: the Authorization Code Flow (response_type=code), the Implicit Flow (response_type=id_token token or response_type=id_token), or the Hybrid Flow (using other Response Type values defined in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]). The flows determine how the ID Token and Access Token are returned to the Client.

The characteristics of the three flows are summarized in the following non-normative table. The table is intended to provide some guidance on which flow to choose in particular contexts.

The flow used is determined by the response_type value contained in the Authorization Request. These response_type values select these flows: