OpenID Connect (OIDC)

OpenID Connect (OIDC) is an authentication layer built on top of OAuth 2.0 (RFC 6749) that standardizes user sign-in and identity exchange between applications. It defines how clients (Relying Parties, or RPs) can verify a user’s identity using ID tokens, typically JSON Web Tokens (JWTs) and retrieve profile information securely. Developed by the OpenID Foundation, OIDC bridges the gap between OAuth’s authorization focus and modern authentication needs.

Key Capabilities

• Standards-based authentication: Uses ID tokens (signed with JWS or encrypted with JWE) to convey authentication details and user identifiers (sub). Clients validate tokens using the OpenID Provider’s (OP) JWKS and discovery metadata.

• Discovery and metadata: Enables automatic configuration of endpoints and capabilities via a .well-known/openid-configuration document, leveraging OAuth 2.0 Authorization Server Metadata (RFC 8414).

• Scopes and claims: Employs the openid scope as a baseline, with optional scopes like profile, email, and address to request standard user claims. Additional custom attributes can be retrieved via the UserInfo endpoint.

• Interoperability: Includes certified conformance profiles to ensure consistent RP and OP implementations across ecosystems (e.g., Google, Microsoft, LoginRadius, Auth0).

Limitations

• Authentication vs. authorization: OIDC provides authentication and identity assertions; authorization remains the domain of OAuth 2.0. Access tokens should not be treated as proof of identity.

• Provider variance: Different OPs may vary in default claims, refresh token handling, and supported extensions. Always rely on discovery metadata and validate key token fields (iss, aud, exp, nonce).

• Security profiles: While flexible by design, higher-assurance deployments often require OAuth 2.0 extensions such as PAR (RFC 9126), DPoP (RFC 9449), or mTLS (RFC 8705) to strengthen token binding and authorization requests.

• Session and logout handling: Managing browser sessions across multiple RPs can be complex. Consistent adoption of the same logout model (front-channel or back-channel) between OPs and RPs is essential for reliable session termination.