OpenID Connect (OIDC)

Learn about the identity layer built on OAuth 2.0, enabling secure authentication and user profile sharing across applications.

What is OpenID Connect (OIDC)?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that provides standardized authentication. It enables applications to verify user identities and obtain basic profile information in a secure, interoperable way. OIDC is widely used for single sign-on (SSO) and federated identity scenarios.

How OIDC Works

OIDC extends OAuth 2.0 by adding an ID token (a JWT) that contains user identity information. The flow is similar to OAuth 2.0 but includes additional identity-specific components:

  1. Authentication Request: Client requests user authentication
  2. User Authentication: Authorization server authenticates the user
  3. Authorization Grant: User approves the request
  4. Token Response: Client receives an ID token + access token
  5. UserInfo Request: Client retrieves additional user details (optional)
User → (1) Login Request → Client
Client → (2) Redirect to OIDC Provider → User
User → (3) Authenticate → OIDC Provider
OIDC Provider → (4) ID Token + Access Token → Client
Client → (5) Validate ID Token → User Identity Confirmed
Client → (6) Request UserInfo (Optional) → OIDC Provider

Key OIDC Components

1. ID Token

  • A JWT containing user identity claims (e.g., sub, email, name)
  • Signed by the OIDC provider to ensure integrity
  • Example:
    {
      "sub": "1234567890",
      "name": "John Doe",
      "email": "john@example.com",
      "iat": 1516239022,
      "exp": 1516242622
    }
    

2. UserInfo Endpoint

  • Provides additional user claims (e.g., address, phone_number)
  • Requires the access token for authorization

3. Scopes and Claims

  • Scopes: Define the level of access (e.g., openid, profile, email)
  • Claims: Individual pieces of user information (e.g., name, email_verified)
ScopeClaims Included
openidRequired for OIDC (includes sub claim)
profilename, family_name, given_name, picture, locale, etc.
emailemail, email_verified
addressaddress (street, city, country, etc.)
phonephone_number, phone_number_verified

4. OIDC Flows

OIDC supports multiple authentication flows, all based on OAuth 2.0 grant types:

FlowUse CaseSecurity Level
Authorization CodeWeb apps, server-side apps (most secure)High
ImplicitSingle-page apps (deprecated in OIDC Core 1.0)Low
HybridCombines authorization code and ID token in the front channelMedium

OIDC vs. OAuth 2.0

FeatureOAuth 2.0OpenID Connect (OIDC)
PurposeAuthorization (access to resources)Authentication (identity)
TokensAccess tokenAccess token + ID token
User InfoNot standardizedStandardized claims
DiscoveryNo standard discovery.well-known/openid-configuration
Use CaseAPI accessUser login and profile data

OIDC Security Considerations

1. ID Token Validation

  • Verify the signature (using the provider's public keys)
  • Check the issuer (iss) matches the expected OIDC provider
  • Validate the audience (aud) matches your client ID
  • Ensure the token hasn't expired (exp)
  • Check the nonce (nonce) to prevent replay attacks

Example (Node.js with openid-client):

const { Issuer } = require('openid-client');

const validateIdToken = async (idToken, client) => {
  const tokenSet = await client.validateIdToken(idToken);
  if (tokenSet.nonce !== expectedNonce) {
    throw new Error('Invalid nonce');
  }
  return tokenSet.claims();
};

2. Secure Token Storage

  • Store tokens in HTTP-only, Secure, SameSite cookies
  • Avoid localStorage (vulnerable to XSS)

3. Prevent Token Leakage

  • Use short-lived tokens (e.g., ID tokens expire in 5 minutes)
  • Never expose tokens in URLs or logs

4. Use PKCE for Public Clients

  • Protects against authorization code interception
  • Required for mobile and single-page apps

5. Implement Logout

  • RP-Initiated Logout: Client requests user logout from the OIDC provider
  • Front-Channel Logout: Provider notifies other clients via iframes
  • Back-Channel Logout: Provider sends logout tokens to clients

OIDC Best Practices

1. Use the Authorization Code Flow

  • The most secure flow for web and mobile apps
  • Combine with PKCE for enhanced security

2. Validate All Tokens

  • Always validate ID tokens and access tokens
  • Use the provider's JWKS endpoint to verify signatures

3. Implement Session Management

  • Use session cookies with short expiration times
  • Support single logout to terminate all sessions

4. Secure Redirect URIs

  • Register exact redirect URIs (no wildcards)
  • Validate URIs on the server side

5. Monitor and Log

  • Track authentication attempts to detect anomalies
  • Log failed attempts and token validation errors

6. Use Discovery for Configuration

  • Leverage the OIDC Discovery endpoint (/.well-known/openid-configuration)
  • Example: https://auth.example.com/.well-known/openid-configuration

Real-World Examples

Social Login

  • "Login with Google" uses OIDC to authenticate users and retrieve profile data
  • Scopes: openid email profile

Enterprise SSO

  • Companies use OIDC for single sign-on across internal apps
  • Example: Employees log in once to access email, HR, and project tools

Government Services

  • Login.gov uses OIDC to provide secure authentication for U.S. government services
  • Supports multi-factor authentication (MFA) for high-security applications

OIDC Extensions and Standards

  • OIDC Core: Defines the core authentication flows (RFC 6749 + OIDC extensions)
  • OIDC Discovery: Standardized provider configuration (RFC 8414)
  • OIDC Dynamic Registration: Client registration at runtime
  • OIDC Session Management: Defines logout and session monitoring
  • OIDC Front-Channel Logout: Logout via iframes
  • OIDC Back-Channel Logout: Logout via direct server communication

Further Reading