What is OIDC: From why we need it to how it works

OpenID Connect (OIDC) definition#

OpenID Connect (OIDC) is an identity authentication protocol built on top of OAuth 2.0. While OAuth 2.0 only provides authorization, OIDC adds authentication capabilities, offering a more standardized solution for user authorization and authentication scenarios.

Simply put: OIDC = Authorization Protocol + Identity Authentication.

Why OIDC is needed?#

To understand why OIDC is needed, let's first explore the core concepts and workflow of OAuth 2.0, and its limitations in practical applications. Through analyzing specific scenarios, we'll see why we need OIDC over OAuth 2.0.

Key concepts and authorization flow of OAuth 2.0#

OAuth 2.0 (Open Authorization) is an authorization protocol that lets users grant third-party applications access to their resources without sharing their credentials like usernames and passwords. It involves four main roles:

• Resource Owner: The user who owns the resources
• Resource Server: The server storing user resources
• Client: The third-party application requesting access to user resources
• Authorization Server: The server that verifies user identity and issues access tokens

A typical OAuth 2.0 authorization flow works like this:

As shown, OAuth 2.0 mainly handles issuing access tokens for third-party clients to access user resources.

The limitation of OAuth 2.0#

OAuth 2.0 protocol only focuses on issuing access tokens. The resource server validates these tokens and returns the authorized resources. However, the resource server doesn't know the user's identity.

This wasn't a significant issue in the early internet ecosystem.

However, as platforms like Google, Facebook, Twitter, and Github evolved, they began offering rich user resources that became valuable for third-party applications.

While OAuth 2.0 excels at authorizing third-party access to user resources, it has limitations. A typical scenario is: since user information is also a resource, when third-party applications need to access basic user information, different platforms (like Google, Facebook, Twitter) return user information in different formats, creating challenges for developers.

OIDC was created to address these challenges.

Roles in OIDC#

To enable user authentication on top of OAuth 2.0 and address its limitations, OIDC introduced three roles:

• End User (EU): The final user, corresponding to OAuth 2.0's Resource Owner
• Relying Party (RP): The dependent party, corresponding to OAuth 2.0's Client
• OpenID Provider (OP): The identity authentication service provider, corresponding to OAuth 2.0's Authorization Server and Resource Server

The OP is the core role, providing both OAuth 2.0's authorization functionality and treating user information as a separate resource.

How does OIDC work?#

OIDC's authentication process is similar to OAuth 2.0, but since OP combines the roles of Authorization Server and Resource Server, it returns both an Access Token and an ID Token. The ID Token contains user identity information, and the RP can verify the user's identity by validating the ID Token.

A typical workflow looks like this:

This standardizes how user information is obtained across different platforms, eliminating the need for third-party applications to handle platform-specific differences.

ID token (identity token) in OIDC#

When users authorize third-party applications, the OP returns both an OAuth 2.0 Access Token and a JWT-format ID Token. This ID Token contains user identity information like user ID, username, email, and avatar. The RP can confirm the user's identity by validating the ID Token.

As a JWT, the ID Token contains standardized claims, including these required core claims:

• iss (Issuer): Unique identifier of the OpenID Provider issuing the ID Token
• sub (Subject): Unique identifier of the user
• aud (Audience): Identifier of the client application receiving the ID Token
• exp (Expiration Time): When the ID Token expires
• iat (Issued At): When the ID Token was issued

For detailed information about ID tokens, please refer to: ID token.

Userinfo endpoint#

The UserInfo Endpoint is a standardized HTTP API provided by the OP to obtain authenticated user details. By sending GET or POST requests with an Access Token to this endpoint, you can receive user information in JSON format. The returned data includes standardized fields like unique user ID (sub), username (name), email, and picture.

The process of getting userinfo follows the same pattern as accessing protected resources in OAuth 2.0. Usually, the user information obtained from the userinfo endpoint is more comprehensive than what's in the ID token, as the ID token primarily serves for identity authentication and basic user information.

For detailed information about the Userinfo endpoint, please refer to: Userinfo endpoint.

Note that the user information you receive from the userinfo endpoint depends on the requested scopes and permissions granted during authorization.

Scopes in OIDC#

Scopes in OIDC define what user information the RP can access. OIDC defines standard scopes, with the openid scope being mandatory in OIDC authentication flows.

Common standard scopes include:

• openid: Indicates an OIDC authentication request
• profile: Basic user information like name and avatar
• email: User's email information
• phone: User's phone number
• address: User's address information

Different scopes return different user information. For example, requesting openid profile email returns basic user information and email in the ID Token and Userinfo, while openid profile email phone address includes phone number and address information as well.

Identity management based on OIDC#

OIDC isn't just an authentication protocol; it's a powerful tool for building flexible, scalable identity management systems. By adding an authentication layer to OAuth 2.0, standardizing user information resources, and laying the foundation for extended identity management features, OIDC enables various identity management scenarios:

• Single Sign-On (SSO): OIDC naturally supports SSO through extended user session information, enabling unified login state management and cross-application identity sharing
• Organization structure management: Extended user organization information can manage complex organizational structures, including department hierarchies and user group relationships
• Permission management: Extended user permission attributes enable fine-grained resource access control, including role information and permission policy configuration

OIDC's flexibility adapts to evolving identity management needs. Many identity management systems are built on OIDC, such as Logto, which provides SSO, organization management, and permission management features.