ID Token

An ID Token is a JSON Web Token (JWT) composed of three Base64Url-encoded parts separated by dots: a Header, a Payload, and a Signature.

• Header: Contains metadata like the token type (JWT) and the signing algorithm (e.g., RS256).
• Payload: Contains the claims about the user and the authentication event. Standard claims include sub (subject/user ID), iss (issuer), aud (audience/client ID), exp (expiration time), and iat (issued at time).
• Signature: Created by signing the encoded header and payload, allowing the client to verify the token's integrity and authenticity.

The token's payload contains a set of claims that provide identity information. These are categorized as:

• Standard Claims: Pre-defined by the OpenID Connect specification (e.g., name, email, preferred_username).
• Custom Claims: Additional claims specific to the identity provider or application.
• Authentication Context Claims: Details about the authentication event itself, such as auth_time (when authentication occurred) and acr (Authentication Context Class Reference, indicating the method used, like MFA).

Example: {"sub": "12345", "name": "Jane Doe", "email": "[email protected]", "iss": "https://auth.example.com", "aud": "my-client-app"}

The client application (RP - Relying Party) must validate the ID Token before trusting its contents. Critical validation steps include:

• Verify the signature using the issuer's public keys (from the JWKS endpoint).
• Confirm the aud (audience) claim matches the client's own ID.
• Check the iss (issuer) claim matches the expected authorization server.
• Validate the token's timestamps: ensure it is not expired (exp) and that it was issued in a reasonable timeframe (iat).
• Reject tokens that do not pass all checks. This validation is a security requirement to prevent token tampering and replay attacks.

It is crucial to understand the different roles of ID Tokens and Access Tokens in the OAuth 2.0 / OIDC ecosystem:

• ID Token: Purpose is authentication. It answers "Who is the user?" It contains identity claims, is for the client application, and should not be sent to a resource API.
• Access Token: Purpose is authorization. It answers "What can the client do?" It contains scopes and permissions, is for the resource server (API), and is used to authorize API calls.

Mixing their purposes is a common security anti-pattern. The ID Token proves login; the Access Token grants API access.

The ID Token is typically issued as part of the OIDC Authorization Code Flow, the most secure and common flow for web and mobile apps.

1. User authenticates at the Authorization Server.
2. Server returns an authorization code to the client.
3. Client exchanges the code + PKCE verifier for tokens at the Token Endpoint.
4. The Token Endpoint response includes both an Access Token and the ID Token.

This flow keeps the ID Token secure from exposure in browser redirects. The nonce parameter is used during the initial request and must be validated against the nonce claim in the ID Token to prevent replay attacks.

Handling ID Tokens requires adherence to security best practices:

• Always Validate: Never trust a token without full cryptographic and claim validation.
• Use nonce: Mandatory for public clients (SPAs, mobile apps) to mitigate replay attacks.
• Short Lifespan: ID Tokens should have a short expiration (e.g., minutes). They are not for long-term API access.
• Secure Storage: Store ID Tokens securely on the client side (e.g., in HTTP-only, Secure, SameSite=Strict cookies for web apps).
• Follow Standards: Implement the OpenID Connect Discovery and Dynamic Client Registration protocols where possible for robust, maintainable integrations.
• Leverage Standard Libraries: Use well-audited libraries for JWT validation instead of writing custom parsing logic.