OpenID Connect (OIDC)

The ID Token is a JSON Web Token (JWT) that is the core artifact of OpenID Connect. It contains claims about the authentication of an end-user, such as the issuer (iss), subject (sub), audience (aud), and expiration time (exp). Unlike an OAuth Access Token, which is for authorization, the ID Token is intended for the client to verify the user's identity. It is always signed, and optionally encrypted, to ensure its integrity and confidentiality.

• Structure: A standard three-part JWT (header, payload, signature).
• Key Claims: Includes iss (Identity Provider), sub (unique user identifier), aud (client ID), exp (expiration), iat (issued at), and auth_time.
• Verification: The client must validate the JWT signature, the issuer, the audience, and the token's expiration.

The UserInfo Endpoint is a protected OAuth 2.0 resource endpoint that returns claims about the authenticated end-user. The client accesses it by presenting the OAuth Access Token obtained during the authentication flow. The returned claims are typically in JSON format and can include standard profile information like name, email, and picture.

• Access Method: Called via an HTTP GET or POST request with the Bearer Access Token.
• Standard Claims: Returns a JSON object with claims defined in the OpenID Connect specification (e.g., name, given_name, family_name, email, picture).
• Relationship to ID Token: Provides a mechanism to fetch fresh or additional user attributes without bloating the initial ID Token.

OpenID Connect defines standardized mechanisms for clients to dynamically discover an Identity Provider's configuration and register themselves.

• Discovery: The OpenID Connect Discovery specification defines a well-known endpoint (e.g., /.well-known/openid-configuration) where clients can retrieve the provider's metadata, including authorization endpoint URLs, supported scopes, and public key locations. This eliminates the need for manual configuration.
• Dynamic Registration: The OpenID Connect Dynamic Client Registration protocol allows clients to programmatically register with an Identity Provider, obtaining a client_id and client_secret. This is essential for multi-tenant SaaS applications or developer platforms.

The authorization framework upon which OIDC is built. While OAuth 2.0 provides delegated access scopes for APIs (the 'what can you do'), OIDC adds a standardized identity layer (the 'who are you').

• Core Grant Types: Authorization Code, Client Credentials, Resource Owner Password Credentials, Implicit.
• Key Distinction: OAuth 2.0 returns an access token for resource access; OIDC returns both an access token and an ID Token containing user identity claims.

The compact, URL-safe token format used by OIDC to transmit identity claims. An OIDC ID Token is a specific type of signed JWT.

• Structure: Header (algorithm), Payload (claims), Signature.
• Standard Claims: sub (subject/user ID), iss (issuer), aud (audience), exp (expiration).
• Verification: Clients must validate the JWT signature (using the issuer's public keys from the JWKS endpoint), audience, and expiration to prevent token tampering.

An older, XML-based standard for enterprise federated identity and Single Sign-On (SSO). OIDC is often seen as its modern, JSON/REST-based successor.

• Comparison: SAML is verbose (XML) and typically used in browser-based enterprise SSO. OIDC is lighter (JSON), designed for modern web/mobile/native apps and APIs.
• Use Case: SAML remains prevalent in many corporate intranets and legacy systems, while OIDC dominates consumer-facing and modern API-driven applications.

A critical security extension to the OAuth 2.0 Authorization Code flow, now mandatory for OIDC public clients (e.g., mobile apps, SPAs). It prevents authorization code interception attacks.

• Mechanism: The client creates a code verifier (random string) and a derived code challenge. The challenge is sent during the authorization request; the verifier is sent during the token request. The server compares them.
• OIDC Integration: PKCE is strongly recommended or required for all OIDC flows involving public clients to mitigate man-in-the-middle risks.