Evolution of Authentication on the Internet -4 #OIDC
OpenID Connect (OIDC)
The following is a continuation of the Evolution of Authentication on the Internet series. Previously we outlines the authentication flows defined under the OAuth specification:
In the following writeup we build on the OAuth fundamentals by discussing OIDC.
OIDC (OpenID Connect)
While the evolution of OAuth 2.0 specification falls under the purview of IETF (Internet Engineering Task Force) OAuth Working Group, the OIDC standardization is governed by the OpenID Foundation.
The latest OIDC specification is OpenID Connect Core 1.0 incorporating errata set 2. ("errata" means corrected errors)
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authorization performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OIDC also mandates the usage of TLS for the IDP (Authorization Server) as recommended under OAuth 2.0.
OpenID Connect implements authentication as an extension to the OAuth 2 authorization process. Usage of this extension is requested by clients by including the openid scope value in the Authorization Request. Information about the authentication performed is returned in a JWT called an ID token.
ID Token
The ID token is represented as a JWT that contains Claims about the authentication of an end-user by an authorization server, and potentially other requested claims. The specification explicitly mentions the following claims:
iss (REQUIRED): Issuer Identifier
sub (REQUIRED): Subject Identifier
aud (REQUIRED): Audience that this ID token is intended for.
exp (REQUIRED): Expiration Time of the ID token.
iat (REQUIRED): Time are which the JWT was issued.
auth_time: Time at which the End-User authentication occurred(no of seconds)
nonce: String value used to associate a Client session with an ID token.
acr: Authentication Context Class Reference.
amr: Authentication Methods Reference.
azp: Authorized party.
ID tokens may contain other claims, depending on the vendor implementation.
OIDC Flows
There are 3 flows defined under the specification:
Authorization Code Flow
Implicit Flow
Hybrid Flow
The flow to be used is determined by the "response_type" value contained in the Authorization request.
* Note that OAuth 2.0 defined the "code" and "token" response_types. OpenID Connect does not use the "token" response_type since no ID token would be returned.
Authorization Code Flow
The Authorization code flow specified under OIDC is identical to the one defined under OAuth 2.0. The only difference is annotated in Bold, where the openid scope is mandatory in the authorization request to use the flow.
Using the openid scope returns the ID token additionally to the Access Token covered under OAuth 2.0.
Implicit Flow
The OIDC Implicit Flow again is identical to the Implict Grant defined under OAuth 2 .0. Note that the response_type parameter under OAuth 2.0 was token. Under OIDC, since the Identity layer has been added the response_type parameter uses the id_token and id_token token values to retrieve ID Tokens. (Refer the table above)
Hybrid Flow
The OIDC Hybrid Flow is an overlay of both the Authorization Code and Implicit Flows. If the code response_type parameter is used with any other parameter combination (such as id_token, token, etc. - Refer the table above); the above flow would manifest. Whether the Access token/ID Token would be received in the authorization request itself is driven by the response_type parameter.
OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 (CIBA)
OIDC is also extended with additional use cases. One of the popular extensions is the CIBA flow which resembles the Device Grant Flow discussed under one of the OAuth 2.0 extensions.
"This specification has the concept of a Consumption Device (on which the user interacts with the Relying Party) and an Authentication Device (on which the user authenticates with the OpenID Provider and grants consent). This specification allows a Relying Party that has an identifier for a user to obtain tokens from the OpenID Provider. The user starts the flow with the Relying Party at the Consumption Device, but authenticates and grants consent on the Authentication Device." – Spec
Approved in 2019.
While the Device Grant Flow under OAuth 2.0 outlined the polling flow via the Device; CIBA adds two other mechanism for the device (service provider) to obtain authentication. The Service Provider can register for the CIBA flow using the following mechanisms:
POLL Mode where the SP queries the Authorization server for the authentication status.
PUSH Mode where the Authorization server returns the relevant tokens to the SP post successful authentication (via the user registered device).
PING mode where the Authorization server “pings“ the SP that the user is successfully authenticated. The SP then requests the tokens from the Authorization server.
OAuth 2.0 / OpenID Connect Ecosystem
Based on the above discussion around OIDC and the previous discussion around OAuth; it becomes clear that strictly reducing the scope of either specification to a single RFC/Document is not fair.
When we say an application is OAuth compliant, we need further details to understand the supported flows.
When we say an application is OIDC compliant, we need further details to understand the supported flows. (However it is safe to assume the mandatory concept of ID Token for OIDC compliance.)
Each vendor implements these specifications with their own flavor. The following diagram attempts to outline the entire ecosystem of RFCs/specifications that relate to OAuth and OIDC. This contains some specifications as late as December 2023.
More and more extensions are being developed to cover newer use cases.
Summary
We discussed the OIDC extension on top of OAuth 2.0. This concludes most of the modern use cases around delegated authorization.
In the following post, we will conclude the “Evolution of Authentication on the Internet“ series by discussing ancillary concepts that are commonly used and also briefly outline the future of authentication use cases.