OpenID Connect (OIDC)

OIDC reuses the OAuth authorisation code flow and adds three things. An openid scope that requests identity. An ID token, a signed JWT containing claims such as the subject identifier, the issuer, the audience, the authentication time and a nonce. And a discovery document at a well-known path that publishes the issuer’s endpoints and signing keys, so a client can validate tokens without manual configuration. It is the protocol behind most modern single sign-on integrations.

Validation is the whole security model and it is a checklist, not a preference: verify the signature against the published keys, confirm the issuer is who you expect, confirm the audience is your client identifier, confirm the token has not expired, and confirm the nonce matches the one you sent. A token that fails any of these is not an identity assertion.

Audience is skipped. An application that validates the signature and the issuer but not the audience will accept a token that the same issuer minted for a completely different application, which means any other client of that identity provider can sign in as any user. In a large identity platform with many registered applications, that is a real and reachable path.

The second is using the access token where the ID token belongs. An access token is opaque to the client by design and is meant for the resource server; treating its contents as identity is the same category error as using OAuth for authentication, one level down.

The third is trusting a mutable claim as the account key. Linking accounts by email address rather than by the immutable subject identifier means anyone who can change or claim an email address at the provider can take over the matching local account, and providers that allow unverified addresses make that trivial. The fourth is accepting a token whose issuer is read from the token itself, which is validation in name only.

We test the validation, not the flow: present a well-formed token from another audience, one with an unexpected issuer, one with a modified signature algorithm, and one that has expired, and record which the application accepts. The finding names the check that was missing and shows the session obtained with it. We also review how accounts are linked and whether the provider verifies the claims used for linking. This is part of how we test federated authentication on an API.