Skip to main content

Introduction

OpenID Connect (OIDC) is a widely adopted authentication protocol that builds on top of OAuth 2.0, enabling users to authenticate with third-party applications using their existing online identities. OIDC operates through the exchange of tokens between an OpenID Connect Provider (OP), a Relying Party (RP) (the third-party application, also identified as Client), and an End-User.

OIDC is designed to be easy to use and flexible, and it supports a variety of authentication flows, including the authorization code flow, implicit flow, hybrid flow, and the direct authentication flow. These flows provide different options for integrating with OIDC depending on the use case and security requirements.

One of the key benefits of OIDC is that it enables secure and privacy-preserving authentication across different domains and applications. It does this by allowing users to authenticate with their identity provider and then share only the necessary information with the relying party, without compromising their passwords or other sensitive information.

OIDC supports claims, which provide additional information about the user, such as their email address, name, or preferred language. This can help the relying party personalize the user's experience and tailor their interactions with the application.

OIDC is a powerful and flexible authentication protocol that enables users to authenticate with third-party applications using their existing online identities, while preserving their security and privacy. It is widely used in modern web and mobile applications and is a foundational technology for identity and access management.

Who are OpenID Connect players?

OIDC involves three main players: the End-User, the Relying Party, and the OpenID Connect Provider. Here's a more detailed description of each player:

  • End-User: The end-user is the entity that owns the identity that the relying party wants to authenticate. The end-user is typically a person, but can also be a device or service account.

  • Relying Party (RP): The relying party is the application that wants to authenticate the end-user. The relying party initiates the OIDC flow by requesting authentication from the end-user.

  • OpenID Connect Provider (OP): The OpenID Connect Provider is the entity that authenticates the end-user and provides identity information to the relying party. The OpenID Connect Provider is responsible for verifying the identity of the end-user, issuing ID Tokens, and managing user sessions.

In an OIDC flow, the relying party requests authentication from the end-user by redirecting the end-user to the OpenID Connect Provider. The end-user then authenticates with the OpenID Connect Provider, which issues an ID Token containing identity information about the end-user. The relying party uses this ID Token to authenticate the end-user and to access additional user information from the OpenID Connect Provider.

What are OpenID Connect flows?

OIDC is built on top of the OAuth 2.0 protocol and includes all of the OAuth 2.0 flows with an additional flow called the Hybrid Flow. OIDC adds an optional id_token to each flow to provide user identity information.

  • Hybrid Flow: this flow is a combination of the OIDC Implicit flow and the OIDC Authorization Code flow. It was introduced to address certain use cases where the Implicit flow or the Authorization Code flow alone were not sufficient. In the Hybrid flow, the relying party requests specific types of tokens (ID token, access token, and/or refresh token) using a combination of the response_type parameter values. For example, the relying party can request an ID token and an access token in a single Hybrid flow request. When the user is authenticated, the OP responds with an authorization code and an ID token (and/or an access token), depending on the requested response_type values. The relying party can then exchange the authorization code for an access token and a refresh token by sending a token request to the OP's token endpoint. The Hybrid flow has several advantages over the Implicit flow and the Authorization Code flow. It allows for the relying party to receive an ID token and/or an access token without requiring additional round-trips to the OP's authorization server. This can improve performance and reduce latency. The Hybrid flow provides a higher level of security than the Implicit flow, as the ID token and access token are returned to the relying party in separate parameters. This makes it more difficult for an attacker to steal the access token using a cross-site scripting (XSS) attack. The following diagram describes the case in with an ID token and an authorization code are asked using the response_mode=id_token code.

Figure 1 - Hybrid Flow

What is an ID token?

In the context of OIDC, an ID Token is a JSON Web Token (JWT), potentially signed and encrypted, that contains information about the authenticated user. The ID Token is issued by the OP as part of the OIDC authentication flow and is sent to the client application alongside the access token.

The ID Token contains a set of claims that provide information about the user, such as the user's unique identifier, name, email address, and other profile data. The ID Token is also signed by the OP using its private key, which allows the client application to verify the authenticity of the token and ensure that it has not been tampered with.

The client application can use the ID Token to authenticate the user and access the user's profile information. The ID Token can also be used to establish a session between the client application and the user, allowing the user to access protected resources on the client application's behalf without having to authenticate again.

It's important to note that the ID Token is not meant to be used as an authorization mechanism, as it only provides information about the user's identity. Instead, the access token should be used to authorize the client application to access protected resources on the user's behalf.

Userinfo endpoint

The Userinfo Endpoint is an optional endpoint in the OIDC protocol that allows the client application to obtain additional information about the authenticated user, beyond what is contained in the ID Token.

After a user has been authenticated, the client application can make a request to the Userinfo Endpoint to retrieve additional user information, such as the user's name, email address, and other profile data. The Userinfo Endpoint returns a JSON object containing these claims, which are similar to the claims in the ID Token.

The Userinfo Endpoint is accessed using an HTTP GET or POST request with an access token in the Authorization header, similar to how the access token is used to access protected resources in OAuth 2.0.

OpenID Connect Single Logout mechanism

OIDC provides several mechanisms for implementing logout between a RP and an OP.

  • Front-Channel Logout: In this mechanism, the RP sends a logout request to the OP's end session endpoint over the front-channel (e.g., the user's browser). The OP then sends a logout request to all other RPs that have previously authenticated the user. The main advantage of front-channel logout is that it can ensure that the user's session is terminated across all RPs. However, it also has security risks such as cross-site request forgery (CSRF) attacks.

  • Back-Channel Logout: This mechanism involves sending a logout request from the RP to the OP's end session endpoint over a secure back-channel (e.g., direct server-to-server communication). The OP then sends a logout request to all other RPs that have previously authenticated the user. Back-channel logout is more secure than front-channel logout because it is not susceptible to CSRF attacks. However, it can be more difficult to implement because it requires secure server-to-server communication.

  • Session Management: OIDC defines a set of session management mechanisms that allow the RP and OP to manage user sessions. This includes the ability to check the status of a user's session, to refresh the user's session, and to end the user's session. The session management mechanisms can be used in conjunction with front-channel or back-channel logout to ensure that the user's session is properly terminated.

OpenID Provider metadata

OpenID Provider Metadata is a JSON document that contains information about an OP, such as the issuer URL, supported scopes, authorization and token endpoints, token signing algorithm, encryption and signing keys and other important details.

By providing this metadata, the OpenID Connect Provider makes it easy for clients to discover and use its services. Clients can retrieve the metadata document through a well-known URL, which is constructed by appending the suffix /.well-known/openid-configuration to the OP's issuer URL.

The metadata document is described in the OpenID Connect Discovery specification, and it provides a standard way for clients to obtain the necessary information to interact with the OP. This eliminates the need for clients to hard-code configuration details and allows for easier deployment and management of OPs.

The metadata document also includes information about the provider's endpoints, such as the authorization endpoint, token endpoint, and userinfo endpoint. Clients use this information to initiate the authentication flow and obtain access and refresh tokens.

External references