OpenID Connect

External reference: https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation
External reference: https://auth0.com/intro-to-iam/what-is-openid-connect-oidc/
External reference: https://openid.net/specs/openid-connect-core-1_0.html#FormSerialization
External reference: https://openid.net/specs/openid-connect-core-1_0.html#Introduction
External reference: https://openid.net/specs/openid-connect-core-1_0.html
External reference: https://openid.net/connect/
External reference: https://openid.net/specs/openid-connect-basic-1_0.html
External reference: https://connect2id.com/learn/openid-connect

It’s an extension on top of OAuth 2.0 that provides a way for the client to verify the identity of the resource owner resource owner.

It does not say anything about the resource server and let OAuth 2.0 deal with this¹.

They precise only two roles: OpenID Connect Provider and Relying Party ². They don’t even redefine the resource server, while they define the end-user, the provider and the relying party³. Actually, in the standard, there are only two references to the resource server and only anecdotally.

The overview of the flow indeed only shows those actors and only refers to the access token as a side note⁴.

The OpenID Connect Core 1.0 specification defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of Claims to communicate information about the End-User

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

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.

— https://connect2id.com/learn/openid-connect

The ID token resembles the concept of an identity card, in a standard JWT format, signed by the OpenID Provider (OP)

— https://connect2id.com/learn/openid-connect

ID tokens are requested via the OAuth 2.0 protocol, which has been a tremendous success on its own

— https://connect2id.com/learn/openid-connect

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows 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 an interoperable and REST-like manner.

— https://openid.net/connect/

OpenID Connect utilises 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

— https://connect2id.com/learn/openid-connect

ID Token

JSON Web Token (JWT) that contains Claims about the Authentication event. It MAY contain other Claims.

— https://openid.net/specs/openid-connect-basic-1_0.html

OpenID Provider (OP)

OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User

— https://openid.net/specs/openid-connect-basic-1_0.html

Relying Party (RP)

OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.

— https://openid.net/specs/openid-connect-basic-1_0.html

The Code Flow consists of the following steps:

Client prepares an Authentication Request containing the desired request parameters.

Client sends the request to the Authorization Server.

Authorization Server authenticates the End-User.

Authorization Server obtains End-User Consent/Authorization.

Authorization Server sends the End-User back to the Client with code.

Client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.

Client validates the tokens and retrieves the End-User’s Subject Identifier.

— https://openid.net/specs/openid-connect-basic-1_0.html

The Client receives a response with the following parameters as described in Section 4.1.4 of OAuth 2.0 [RFC6749]. The response SHOULD be encoded using UTF-8 [RFC3629].

access_token

REQUIRED. Access Token for the UserInfo Endpoint.

token_type

REQUIRED. OAuth 2.0 Token Type value. The value MUST be Bearer, as specified in OAuth 2.0 Bearer Token Usage [RFC6750], for Clients using this subset. Note that the token_type value is case insensitive.

id_token

REQUIRED. ID Token.

expires_in

OPTIONAL. Expiration time of the Access Token in seconds since the response was generated.

refresh_token

OPTIONAL. Refresh Token.

The Client can then use the Access Token to access protected resources at Resource Servers.

— https://openid.net/specs/openid-connect-basic-1_0.html

The Client MUST validate the ID Token in the Token Response

— https://openid.net/specs/openid-connect-basic-1_0.html

OpenID Connect defines the following scope values:

openid

REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the behavior is entirely unspecified.

profile

OPTIONAL. This scope value requests access to the End-User’s default profile Claims, which are: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.

email

OPTIONAL. This scope value requests access to the email and email_verified Claims.

address

OPTIONAL. This scope value requests access to the address Claim.

phone

OPTIONAL. This scope value requests access to the phone_number and phone_number_verified Claims.

offline_access

OPTIONAL. This scope value requests that an OAuth 2.0 Refresh Token be issued that can be used to obtain an Access Token that grants access to the End-User’s UserInfo Endpoint even when the End-User is not present (not logged in).

— https://openid.net/specs/openid-connect-basic-1_0.html

Use of this extension is requested by Clients by including the openid scope value in the Authorization Request

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs).

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs)

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization, per Section 13.1. If using the HTTP POST method, the request parameters are serialized using Form Serialization

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims.

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

Client MUST validate the Token Response as follows:

Follow the validation rules in RFC 6749, especially those in Sections 5.1 and 10.12.

Follow the ID Token validation rules in Section 3.1.3.7.

Follow the Access Token validation rules in Section 3.1.3.8.

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

Identity Token

The JWT that contains data about the user.

The ID Token is a security token that contains Claims about the authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT) [JWT].

The following Claims are used within the ID Token:

iss

REQUIRED. Issuer Identifier for the Issuer of the response. 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

REQUIRED. Subject Identifier. 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. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case-sensitive string.

aud

REQUIRED. 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. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case-sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case-sensitive string.

exp

REQUIRED. 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 [RFC7159] number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

iat

REQUIRED. Time at which the JWT was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.

auth_time

Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. When a max_age request is made then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.

nonce

OPTIONAL. 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. The Client 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. The nonce value is a case-sensitive string.

at_hash

OPTIONAL. Access Token hash value. This is OPTIONAL when the ID Token is issued from the Token Endpoint, which is the case for this subset of OpenID Connect; nonetheless, an at_hash Claim MAY be present. 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 JOSE Header. For instance, if the alg is RS256, hash the access_token value with SHA-256, then take the left-most 128 bits and base64url-encode them. The at_hash value is a case-sensitive string.

acr

OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value “0” indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. For historic reasons, the value “0” is used to indicate that there is no confidence that the same person is actually there. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. An absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context specific. The acr value is a case-sensitive string.

amr

OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amr Claim is beyond the scope of this document. Parties using this claim will need to agree upon the meanings of the values used, which may be context specific. The amr value is an array of case-sensitive strings.

azp

OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience. The azp value is a case-sensitive string containing a StringOrURI value.

ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.

— https://openid.net/specs/openid-connect-basic-1_0.html

OpenID Connect Provider

A tool that can provide signed ID Token. Basically the authorization server from the point of view of OpenID Connect.

This specification also defines the following terms:

OpenID Provider (OP)

OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User. […]

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows 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 an interoperable and REST-like manner.

— https://openid.net/connect/

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users

— https://openid.net/connect/

OpenID Connect or OIDC is an identity protocol that utilizes the authorization and authentication mechanisms of OAuth 2.0.

— https://auth0.com/intro-to-iam/what-is-openid-connect-oidc/

While OAuth 2.0 is an authorization protocol, OIDC is an identity authentication protocol a

— https://auth0.com/intro-to-iam/what-is-openid-connect-oidc/

used to verify the identity of a user to a client service, also called Relying Party

— https://auth0.com/intro-to-iam/what-is-openid-connect-oidc/

Notes linking here

Permalink

As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. Readers are expected to be familiar with these specifications.

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

↩︎
OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs).

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

↩︎
This specification uses the terms […] “Authorization Server”, “Client”, […] “Resource Owner”, “Resource Server”, […] defined by OAuth 2.0 [RFC6749]

[…]

This specification also defines the following terms:

End-User

Human participant. […]

OpenID Provider (OP)

OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User. […]

Relying Party (RP)

OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.

— https://openid.net/specs/openid-connect-core-1_0.html#Introduction

↩︎

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

1) The [[id:4ba66897-9805-453c-b0d8-94d567c8f79d][RP]] (Client) sends a request to the OpenID Provider ([[id:8f180b6d-f9a8-4244-a3e8-827fd4098835][OP]]).
2) The OP authenticates the End-User and obtains authorization.
3) The OP responds with an [[id:957552a3-2db5-4515-bdbc-b6c373f48afe][ID Token]] and usually an [[id:e8b165d4-cb30-4a18-9d23-990629f09f2d][Access Token]].
4) The RP can send a request with the Access Token to the UserInfo Endpoint.
5) The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

--- https://openid.net/specs/openid-connect-core-1_0.html#Introduction

↩︎