OpenID Connect (OIDC)

The ID Token is a JSON Web Token (JWT) that is the core artifact of the OpenID Connect authentication flow. It contains claims about the authentication event and the authenticated user. Unlike an OAuth access token, which is for authorization, the ID Token is intended for the client to verify the user's identity.

• Structure: Contains a standard set of claims like iss (issuer), sub (subject/user ID), aud (audience/client ID), exp (expiration), and iat (issued at).
• Signature: Must be signed, and often encrypted, using JSON Web Signature (JWS) and JSON Web Encryption (JWE) to ensure integrity and confidentiality.
• Verification: The client must validate the token's signature, audience, issuer, and expiration time to trust the contained identity information.

The UserInfo Endpoint is a protected OAuth 2.0 resource that returns claims about the authenticated end-user. Clients access it by presenting a valid access token obtained during the OpenID Connect flow.

• Data Retrieval: Returns a JSON object with standard profile claims such as name, email, picture, and locale. The specific claims returned are determined by the scope requested (e.g., profile, email).
• Protection: The endpoint must be protected by the OAuth 2.0 Bearer Token usage specification. The client accesses it via a standard HTTP GET request with the access token in the Authorization header.
• Standardization: Provides a consistent, RESTful API for clients to retrieve identity information, separate from the authentication event data in the ID Token.

OpenID Connect defines several authentication flows (or grant types) that specify how a client obtains ID and access tokens. These flows are extensions of OAuth 2.0 authorization grants, optimized for identity verification.

• Authorization Code Flow: The most secure and common flow for server-side applications. The client receives an authorization code via a front-channel redirect, then exchanges it for tokens via a secure back-channel request. This flow supports PKCE (Proof Key for Code Exchange) for public clients.
• Implicit Flow (Deprecated): Previously used for single-page apps, this flow returned tokens directly in the URL fragment. It is now considered less secure and is deprecated in favor of the Authorization Code Flow with PKCE.
• Hybrid Flow: A combination where some tokens (e.g., the ID Token) are returned from the authorization endpoint directly, while others (e.g., an access token) are obtained via the token endpoint.

To simplify integration, OpenID Connect provides mechanisms for clients to dynamically discover an OpenID Provider's configuration and to register themselves.

• Discovery: Defined by the OpenID Connect Discovery specification. Providers publish a JSON document at a well-known URL (e.g., https://issuer.com/.well-known/openid-configuration). This document contains all necessary endpoints (authorization, token, userinfo, jwks), supported scopes, and cryptographic capabilities.
• Dynamic Client Registration: Defined by the OpenID Connect Dynamic Client Registration specification. Allows clients to programmatically register with an OpenID Provider, obtaining a client_id and client_secret. This is essential for multi-tenant SaaS applications and reduces manual configuration overhead.
• Self-Issued OpenID Provider: A variant where the end-user's own software acts as the OpenID Provider, enabling decentralized identity scenarios.

Claims are individual pieces of information about the user or authentication event, while scopes are used to request specific sets of claims.

• Standard Claims: A predefined set of user profile claims like name, family_name, email, email_verified, picture, and sub (the unique subject identifier).
• Standard Scopes: Bundles of claims requested by the client. Core scopes include:
  • openid: Required to initiate an OpenID Connect request.
  • profile: Requests access to default profile claims (name, picture).
  • email: Requests the email and email_verified claims.
  • address and phone: Request address and phone number claims.
• Custom Claims & Scopes: Providers and clients can define additional claims and scopes for specific use cases, which are communicated via the discovery document or registration metadata.

The JWKS endpoint is a publicly accessible URI where the OpenID Provider publishes its cryptographic keys in a JSON Web Key Set format. Clients use these keys to verify the signatures on ID Tokens and optionally encrypt requests.

• Key Publication: The endpoint hosts a JSON object with an array of JSON Web Keys (JWKs). Each key contains its kty (key type, e.g., RSA), kid (key ID), the public key material, and the intended use (e.g., sig for signature verification).
• Signature Validation: When a client receives a signed JWT (like an ID Token), it fetches the JWKS from the provider's endpoint, finds the key matching the token's kid header, and uses it to verify the token's signature.
• Key Rotation: Providers can publish multiple keys and rotate them by advertising new keys in the JWKS and deprecating old ones, allowing for seamless key management without client downtime.

OAuth 2.0 is the authorization framework upon which OIDC is built. It provides the core protocol for delegated access, allowing a client application to obtain limited access to a user's resources on a server without sharing the user's credentials.

• Key Distinction: OAuth 2.0 is about access delegation ("can this app act on my behalf?"), while OIDC adds authentication ("who is this user?").
• Token Types: Primarily uses Access Tokens (for API authorization) and Refresh Tokens. OIDC introduces the ID Token.
• Grant Flows: Defines flows like Authorization Code, Client Credentials, and Device Code for different client types (web apps, machine-to-machine, IoT).

A JSON Web Token is a compact, URL-safe token format (RFC 7519) used to securely transmit claims between parties. The OIDC ID Token is a specific type of JWT.

• Structure: A JWT consists of three Base64Url-encoded parts: Header (algorithm & token type), Payload (the claims), and Signature.
• Signing: JWTs can be signed using algorithms like RS256 (RSA) to ensure integrity and authenticity. They can also be encrypted (JWE).
• Self-Contained: Because they are signed and contain claims, JWTs enable stateless authentication; the API gateway can validate the token without a call to the identity provider for most checks.

Token Introspection (RFC 7662) is an OAuth 2.0 extension that allows a protected resource (like an API gateway) to query the authorization server to check the active state and metadata of an opaque access token.

• Use Case: Complements JWT validation. While JWTs are self-contained, opaque tokens are not. Introspection is the method to validate them.
• Process: The gateway sends the token to the authorization server's introspection endpoint, which returns a JSON response indicating if the token is active and including its scopes, client_id, and expiry.
• Trade-off: Provides real-time token revocation but adds latency and load to the authorization server versus stateless JWT validation.