Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26131:2024 OpenID Connect Core 1.0 — Identity Layer for Modern Authentication
Understanding the core protocol for decentralized identity verification on top of OAuth 2.0
1. Understanding OpenID Connect Core
ISO/IEC 26131:2024 defines OpenID Connect Core 1.0, a simple identity layer built on top of the OAuth 2.0 protocol. It enables clients (Relying Parties) to verify the identity of end-users based on authentication performed by an Authorization Server (OpenID Provider), and to obtain basic profile information in an interoperable, REST-like manner.
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Clients request this extension by including the openid scope value in the Authorization Request. The authentication result is returned in a JSON Web Token (JWT) called an ID Token, which contains claims about the authentication event.
The ID Token is the core innovation of OpenID Connect. Unlike OAuth 2.0 which only provides access tokens for API authorization, the ID Token delivers verifiable identity information directly to the client application using JWT structure with cryptographic signatures.
2. Authentication Flows
The standard defines three primary authentication flows, each suited for different application scenarios:
| Flow Type | Tokens from Auth Endpoint | Tokens from Token Endpoint | Use Case |
|---|---|---|---|
| Authorization Code Flow | Authorization Code | ID Token + Access Token | Server-side web apps with backend |
| Implicit Flow | ID Token + Access Token | None | Single-page applications (legacy) |
| Hybrid Flow | Authorization Code + some tokens | Remaining tokens | High-security native apps |
The Implicit Flow is no longer recommended for new applications due to security concerns with token exposure in URL fragments. The Authorization Code Flow with PKCE (Proof Key for Code Exchange) is now the preferred approach for all client types including SPAs and native apps.
3. Claims, Scopes, and UserInfo Endpoint
OpenID Connect defines standard claims for communicating user information. Claims are pieces of information asserted about an entity, organized into logical groupings called scopes:
| Scope | Claims Returned | Description |
|---|---|---|
openid |
sub (subject identifier) |
Required scope indicating OpenID Connect request |
profile |
name, family_name, given_name, picture, locale, etc. |
Basic profile information |
email |
email, email_verified |
Email address with verification status |
address |
address (JSON object) |
Structured postal address |
phone |
phone_number, phone_number_verified |
Phone number with verification status |
The UserInfo Endpoint is an OAuth 2.0 protected resource that returns claims about the authenticated end-user. When accessing this endpoint, the client presents an Access Token, and the endpoint returns the requested claims as a JSON document.
For engineering teams implementing SSO, always request the minimum scope necessary. Requesting
openid profile email covers most identity verification needs without over-exposing personally identifiable information (PII).4. Security Considerations for Production Deployments
ISO/IEC 26131:2024 dedicates extensive attention to security. Key considerations include:
- TLS Requirements: All communication between the Relying Party and OpenID Provider MUST utilize TLS. This prevents token interception and man-in-the-middle attacks.
- Token Replay Prevention: The
nonceparameter associates a client session with an ID Token, preventing replay attacks even if the token is intercepted. - Pairwise Identifiers (PPID): To prevent correlation across different relying parties, the specification supports pairwise pseudonymous identifiers that are unique per client application.
- Signed and Encrypted Requests: Request objects can be signed (JWS) and encrypted (JWE) to ensure request integrity and confidentiality when passed by reference or value.
Never accept ID Tokens without validating the signature, issuer, audience, and expiration time. A missing or incorrect signature validation is the most common OpenID Connect security vulnerability found in production systems.
5. Engineering Insights and Implementation Guide
When implementing an OpenID Connect integration, consider these engineering best practices:
- Use established libraries: Leverage certified OpenID Connect libraries rather than implementing protocol flows from scratch. The OpenID Foundation maintains a certified implementation list.
- Implement proper redirect URI validation: The redirect_uri MUST exactly match registered values. Use exact string comparison — any pattern matching can introduce open redirect vulnerabilities.
- Rotate signing keys: OpenID Providers should rotate asymmetric signing keys regularly and expose new keys via the JWKS endpoint. Clients should cache keys with appropriate TTL.
- Handle clock skew: ID Token validation must account for clock skew between systems. A recommended tolerance is no more than a few minutes.
Frequently Asked Questions
Q: What is the difference between OpenID Connect and OAuth 2.0?
A: OAuth 2.0 is an authorization framework that grants access to resources using access tokens. OpenID Connect is an authentication layer on top of OAuth 2.0 that adds identity verification via ID Tokens. With OpenID Connect, you get both authentication (who the user is) and authorization (what the user can access).
Q: Can I use OpenID Connect without OAuth 2.0?
A: No. OpenID Connect is specifically designed as an extension to OAuth 2.0. It leverages OAuth 2.0 flows, endpoints, and token mechanisms. You must have an OAuth 2.0 infrastructure in place to implement OpenID Connect.
Q: What is the typical latency for OpenID Connect authentication?
A: In practice, the authentication flow typically completes in under one second when the OpenID Provider is well-provisioned. The critical path involves a TLS handshake, authentication verification, JWT signing, and token response delivery. CDN-backed endpoints and optimized JWK caching can significantly reduce latency.
Q: Is OpenID Connect suitable for IoT and mobile applications?
A: Yes. The Authorization Code Flow with PKCE is specifically designed for mobile and native applications where keeping a client secret is impractical. For IoT devices with limited HTTP capabilities, the standard also supports simpler profiles.
