What Is OpenID Connect?

OpenID Connect is the authentication layer built on top of OAuth. It exists because OAuth delegates authorisation and does not establish identity, and applications kept using it as though it did.

The addition is the identity token: a signed token containing claims about the authenticated user, with an audience restricting which application may accept it. That audience restriction is what closes the vulnerability that arises from using access tokens for login.

Why it displaced SAML for new development

It uses JSON and REST rather than XML and SOAP, which makes it considerably easier to implement correctly in modern applications and far better suited to mobile and single-page applications where browser redirects with large XML payloads are awkward.

It also benefits from discovery: a provider publishes its configuration and signing keys at well-known endpoints, so clients can retrieve and rotate keys automatically rather than having them configured manually and forgotten.

SAML remains widespread and will for years, because enterprise applications have long lives. New integrations generally use OpenID Connect.

What implementations must still get right

Validate the token signature against the provider's published keys. Validate the issuer. Validate the audience — this is the check that prevents a token issued for another application being accepted. Validate expiry. And use the nonce to bind the response to the request that initiated it.

Skipping audience validation in particular reintroduces exactly the confused-deputy problem the protocol was designed to eliminate.

Discovery and key rotation

Providers publish configuration and signing keys at well-known endpoints, which lets clients fetch keys automatically and handle rotation without manual reconfiguration. It is one of the practical advantages over older protocols where key changes broke integrations.

Clients should cache those keys sensibly — refreshing periodically and on encountering an unknown key identifier — rather than fetching on every validation, which creates a dependency on the provider being reachable for every authentication.

Pinning a key rather than using discovery reintroduces the manual rotation problem and is worth avoiding unless there is a specific reason.

Scopes, claims and what the application actually needs

Applications routinely request broad scopes during integration because it makes development easier, and the grant persists. A sign-in integration that requests access to mail, files and calendar when it only needs the user’s identity is requesting standing access to corporate data.

Reviewing what each registered application requests, against what it demonstrably needs, is an exercise most tenants have never performed and which frequently surfaces over-permissioned integrations added years ago.

The same applies to claims included in tokens. Sensitive attributes placed in an identity token travel to every application receiving it, which may be more places than intended.

The thing most worth getting right

Where to start

For your own applications using OpenID Connect, confirm audience validation is actually performed. It is the check most often omitted and the one whose absence is most consequential.

See OAuth for the underlying framework. GuardsArm delivers application penetration testing.