OpenID Connect Overview

What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer on top of the OAuth 2.0 protocol. OIDC allows applications to authenticate users, while OAuth provides ways to authorize resource access. The OpenID Connect protocol specifies an extensible suite for end user identity interaction. It allows all types of applications (which the OAuth spec calls clients and OIDC calls relying parties) to request and receive information about authenticated sessions and end users, as well as providing access to backend APIs using OAuth access tokens. This allows an identity provider to provide clients with end-user identification and basic profile information.

How Does OpenID Connect Work?

OpenID Connect introduces a new type of token, the ID token, that is issued together with an access and optionally a refresh token. The ID token contains claims about the authentication of an end user. Information about the user can include the following standard claims:

For more information regarding the claims used in ID tokens, have a look at the OpenID Connect specification.

The flows to obtain tokens are very similar to common OAuth 2.0 flows. By specifying the parameter scope=openid in the request, the client tells the authorization server to run the OpenID Connect protocol. The identity server that implements the authorization server then also implements the OpenID Provider role.

In general, OpenID Connect works as illustrated:

1. The client sends a request to the identity server asking for authorization and user authentication.
2. The identity server then authenticates the end user.
3. The identity server returns a response to the client with the authentication (and authorization) result.
4. Optionally, the client can then retrieve user details via the UserInfo endpoint.
5. The identity server provides user details to the client.

OpenID Connect Flows

The core OpenID Connect specification describes three OIDC flows:

• OIDC Authorization Code Flow: The most popular flow in OpenID Connect as well as the most flexible. It allows all types of clients to obtain tokens securely.

• OIDC Implicit Flow: The implicit flow was historically included in the specification to allow running OIDC from browser-based clients. Since modern browsers are capable of using the authorization code flow, developers should not use this flow anymore.

• OIDC Hybrid Flow: The hybrid flow is a mix of the implicit flow and the authorization code flow. It allows browser-based clients to obtain tokens in two different ways.

OpenID Connect and Single Sign-On (SSO)

You can use OpenID Connect to achieve SSO. The client starts an OpenID Connect flow and notifies the server of its authentication requirements. The OpenID Provider can reuse previous authentication sessions and if the session fulfills the client’s requirements, allow the user to proceed without interaction.

You may enable single sign-on for both web and mobile platforms with OpenID Connect. In this way, users can log in across multiple websites or applications without having to re-enter their credentials.

OpenID Connect vs. OAuth 2.0

OAuth 2.0 was designed to allow a user to grant an application access to resources outside the client's realm. There is no need for users to share their credentials with the client. Instead, a user delegates access rights to the client. The access token represents the delegated access. It describes what the user permits the client to do on their behalf. However, OAuth 2.0 does not provide any (standardized) way for the client to request or control user authentication.

OpenID Connect adds the missing identity layer to OAuth 2.0. It does so by accepting a number of request parameters that allow applications to control authentication. For example, the client can use the prompt parameter to force the user to re-authenticate. The OpenID Provider can still manage the actual authentication in a myriad of potential ways. Once the user completes authentication, the OpenID Provider returns the ID token to the client as a proof of the authentication event. The client can verify the ID token and create a session. You can use OAuth 2.0 without OpenID Connect and find other means to convey the user's identity to the client.

OpenID Connect vs. SAML

Security Assertion Markup Language (SAML) is a framework for exchanging security assertions. Assertions in this context are statements made by an authority about the subject (end-user), authentication, and authorization decision. They are comparable to claims in OpenID Connect but encoded using XML. Just like OpenID Connect, SAML enables a client to outsource the authentication of a user to an identity provider (IdP). It enables identity federation and lends itself to single-sign-on implementations.

SAML was designed for web-based clients. It is typically coded in websites, which would verify the SAML assertion after login and create a session. SAML does not provide a separate API credential. OpenID Connect, on the other hand, provides a more complete solution for modern apps. Since it is based on OAuth 2.0, OpenID Connect provides an API credential (access token) that can be sent by web and mobile clients to backend APIs.

Benefits of OpenID Connect

• API-friendly: OpenID Connect is API-friendly. It extends OAuth 2.0, defines a protocol for managing authentication, and an API for reading basic user profile information.
• Web and Mobile-friendly: OpenID Connect is a protocol designed to support mobile applications. It works well in both mobile apps and web apps. It supports mobile single sign-on.
• Lightweight Syntax: The message formats are based on JSON. JSON (JavaScript Object Notation) is human-readable, but still suitable for machine parsing. It is language-independent and has simple conventions, making it easy to work with. As it consists of name-value pairs in an ordered list, it is a good data-interchange format.
• Specified Token Format: ID tokens in OpenID Connect are JSON Web Tokens, JWTs (pronounced "jots"). The format is a JSON-based open standard for creating tokens. It includes claims to inform the application when and how authentication occurred, as well as the identity of the user.
• Easy Key Distribution: OpenID Connect provides a key distribution mechanism called JSON Web Key Set (JWKS). There is no need for the overhead of a separate key management and distribution mechanism like a PKI infrastructure.
• Access to User Information: OpenID Connect provides endpoints for clients to use when they need access to user data. It also provides mechanisms for the user to consent before this data is released to the client.

OpenID Connect Use Cases

The OpenID Connect protocol is most commonly used in these scenarios:

• You want your frontend applications to know the user’s identity. A mobile or web application can use OIDC to get information about the authenticated user to personalize the view. For example, it can greet the user with their name or show different parts of the user interface based on some information about the user.
• You want your frontend applications to have a limited control over the authentication flow. For example, with some request parameters the application can ensure that the user performs authentication and not use a Single Sign On session.
• You want to enable federated login to your system. Your applications can start an authentication flow with your authorization server (using OIDC, OAuth, or another protocol), and the server can use OIDC to federate with an external identity provider, like Facebook or Google. In this case, your authorization server becomes a relying party for the OpenID Provider and you are able to authenticate users without the need of managing user credentials.
• OIDC is a fairly simple protocol to implement and you can use it to wrap some more complicated protocols like SAML. Your apps can communicate with your authorization server using OIDC, which then federates the authentication to an external SAML provider. This way you can keep the complex implementation out of your frontend applications.

OpenID Connect: The Internet Identity Layer

OpenID Connect is the leading internet standard for cross-domain single sign-on and identity.

The main benefit of OpenID Connect is that it provides a completely standardized setup. Since it is built on OAuth 2.0, it is API-friendly. It extends the OAuth 2.0 protocol with support for authentication so that the client can verify the identity of its users.

OpenID Connect does not define how authentication should be performed, but it provides a standardized protocol on how to ask for authentication and how the result of authentication should be presented to the client. It uses JWTs (JSON Web Tokens) as the identity token format and works for all kinds of clients, such as web-based, mobile, or native clients. The specification is available on the OpenID foundation website.

This article has been updated on: 2024-09-16Published: 2024-09-16

Curity