OpenID Connect (OIDC)

OpenID Connect Core 1.0 was finalised by the OpenID Foundation in February 2014, replacing the earlier, incompatible OpenID 2.0. It is a profile of OAuth 2.0: a client requests the openid scope, and the provider returns an ID token next to the usual access token. Companion specifications cover Discovery (the /.well-known/openid-configuration document), Dynamic Client Registration and several logout mechanisms. In 2024 Core and eight related specifications were published as international standards ISO/IEC 26131 to 26139, with Core incorporating errata set 2.

The ID token is a JWT signed with JWS (optionally also encrypted). Core §2 requires the claims iss (issuer), sub (subject identifier, locally unique within the issuer and at most 255 ASCII characters), aud (which must contain the client_id), exp and iat, and defines auth_time, nonce, acr (authentication context class), amr (authentication methods) and azp (authorised party). Validation per §3.1.3.7 means checking that iss exactly matches the expected issuer, aud contains the client, the signature verifies with a key from the provider's JWKS using the expected algorithm, the token has not expired and the nonce matches the one the client sent. The only stable user key is the iss plus sub pair; email and preferred_username can change, and an email claim is not proof of ownership unless email_verified is true and the provider is authoritative for that domain.

Three flows are defined: authorization code (response_type=code), implicit (id_token or id_token token) and hybrid (for example code id_token). Current practice, reflected in the OAuth security BCP, is the code flow with PKCE for every client type, with the ID token fetched from the token endpoint. Request parameters give the relying party control: prompt=login and max_age force reauthentication, and acr_values asks for a particular assurance level, which the RP must then verify in the returned acr claim rather than assume. Profiles such as FAPI 2.0 tighten these rules for open banking and similar high-risk APIs.

Common implementation errors are accepting an OAuth access token as proof of login, skipping audience or issuer checks (especially on multi-tenant endpoints, where the tenant claim must also be validated), omitting the nonce, and algorithm confusion, where a library accepts alg "none" or verifies an RS256 token as HS256 using the public key as an HMAC secret. Logout is the weak area: RP-Initiated, Front-Channel and Back-Channel Logout exist, but browsers' blocking of third-party cookies breaks iframe-based session checks and front-channel logout, so back-channel logout tokens are the more reliable choice. Compared with SAML, OIDC uses compact JSON and JWTs over simple redirects and suits single-page, mobile and API scenarios better, while SAML keeps a strong foothold in enterprise SaaS.