Back to Glossary

OpenID Connect (OIDC)

OpenID Connect (OIDC) provides a simple, reliable user authentication process, built on top of OAuth 2.0, to verify identities and retrieve user details. The most well-known example of a OpenID Connect flow is the “Sign in with Google” button that is nearly ubiquitous across the internet today.

OIDC serves web applications by enabling a secure and user-friendly single sign-on (SSO) method, used in both enterprise and consumer contexts. It's trusted by major tech companies and leverages JSON Web Tokens (JWT) for integration into user management systems.

What is OIDC

OIDC is an identity layer built on OAuth 2.0. It allows secure user authentication and identity information in a standardized format. OIDC enables clients to verify end-user identities through authentication performed by an authorization server, obtaining profile details in an interoperable manner.

OIDC uses OAuth 2.0 but adds authentication with ID tokens. These tokens, structured as JWTs, contain claims about the authenticated user, like their email and name. OIDC supports various flows, making it suitable for different application types, from web applications to mobile apps.

Comparison of OIDC and SAML

OIDC and Security Assertion Markup Language (SAML) are key protocols for identity management and SSO. Here's how they compare:

Origin and purpose

  • SAML: Developed in the early 2000s for enterprise SSO, SAML is widely used in enterprises and government applications for secure identity assertions.
  • OIDC: Built on OAuth 2.0 for modern web and mobile applications, OIDC integrates identity assertions into diverse tech environments.

Data format and complexity

  • SAML: Uses XML for data formatting and transport.
  • OIDC: Utilizes RESTful HTTP and lightweight JWTs, making it easier to implement in modern applications.

Security

  • Both Protocols: Provide strong security mechanisms. SAML uses XML encryption and digital signatures, while OIDC uses encrypted JWTs.

Use cases

  • SAML: Suitable for enterprise SSO.
  • OIDC: Suitable for enterprise SSO and social sign-in such as Google.

Implementation and integration

  • SAML: Requires more effort to support a wide variety of configurations.
  • OIDC: Simpler because it's more standardized.

Comparison of OIDC and OAuth 2.0

Although OIDC is technically built on top of OAuth 2.0, the extension only focuses on a small subset of OAuth 2.0 functionality. As a result, OIDC and OAuth 2.0 tend to serve different purposes:

Purpose

  • OAuth 2.0: Focuses on authorization, allowing access to resources without the resource owner's credentials.
  • OIDC: Focuses on authentication to confirm user identity.

Tokens

  • OAuth 2.0: Issues access tokens and refresh tokens.
  • OIDC: Issues ID tokens, in addition to access and refresh tokens.

Security

  • Both Protocols: Leverage the OAuth 2.0 for security.

Implementation

  • OAuth 2.0: Different providers offer different scopes, and research is required to understand how to work with scopes.- OIDC: Simpler because the scopes are standardized across providers.

Technical foundation and core components

OIDC extends OAuth 2.0, adding standardized elements for authentication and profile information.

Key components

The OIDC framework includes:

  1. OpenID Provider (OP): The server that verifies user identity and issues ID tokens.
  2. Relying Party (RP): The application requesting authentication.
  3. ID Token: A JWT containing user claims.
  4. UserInfo Endpoint: A REST endpoint for additional user profile information.

Authentication flows

OIDC supports these flows:

Authorization code flow: Optimal for server-side applications. The process involves redirecting the user to the authorization endpoint and receiving a code to exchange for tokens.

Implicit flow: Designed for client-side applications; less secure and not recommended for new apps.

Hybrid flow: combines Authorization Code and Implicit flows for immediate token access.

Implementation and security considerations

Implementing OIDC involves security best practices and proper configuration.

Security best practices

  • Validate all tokens and verify signatures.
  • Use HTTPS for endpoints.
  • Protect against code interception, such as with PKCE for mobile and native apps.
  • Verify token expiration and audience claims.
  • Store tokens securely.
  • Implement proper session management.

Common implementation issues

Common issues include token validation, refresh token management, handling token expiration, secure session management, and error handling.

Important factors to consider when choosing an OIDC provider

Choosing an OIDC provider requires careful evaluation of various factors.

Reputation and security measures

Assess the provider's reputation and security measures. Choose providers with strong security records and standards compliance.

Support for multiple platforms

Ensure the provider supports all platforms, including web, mobile, and desktop environments, ensuring a consistent user experience.

Documentation and community support

Good documentation and community support can simplify the integration process.

Scopes and permissions

Ensure that the provider allows you to specify the necessary scopes for your application to avoid privacy concerns.

OIDC includes built-in consent mechanisms. Ensure that the provider facilitates user consent.

Authentication methods

The provider should offer various authentication methods to accommodate diverse user preferences.

Integration with existing systems

Check if the provider can integrate with your existing identity systems, supporting hybrid approaches.

Multi-factor authentication (MFA)

The ability to request MFA from the provider enhances security.

Identity provider support

Ensure that the chosen IdP supports OIDC and aligns with your application needs.

By considering these factors, you can select an OIDC provider that supports your application’s authentication needs.

Integration with Clerk

Clerk supports OIDC, simplifying secure authentication. Clerk manages token and session handling while ensuring security and smooth integration through OIDC endpoints.

Clerk offers:

  • Support for common OIDC providers like Google, Microsoft, Github, and many more for SSO in a consumer context.
  • Support for common Google and Microsoft OIDC for EASIE SSO in an enteprise context.
  • Support for custom OIDC providers, for both enterprise and consumer contexts.
  • Built-in token validation and management.
  • Secure session handling.
  • User profile synchronization.
  • Automated access token refresh.

Access guides in Clerk Docs.

Related terms