OIDC & Federation

An application receives an access token from a provider, calls the userinfo endpoint, gets back an email address, and logs the person in. It looks entirely reasonable and it is a real vulnerability: an access token is a bearer credential issued to some application for some scope, and a malicious app that obtained one for its own purposes can present it to yours. Nothing in that token says who it was issued for, because OAuth never promised to answer that question. OpenID Connect exists to answer it properly, and this track is about the difference.

The core distinction is two tokens with two jobs. An access token is for calling an API on the user's behalf; your application should treat it as opaque and not read identity out of it. An id_token is a signed statement from the identity provider about the authentication event itself — who the subject is, when they authenticated, which client it was issued to, and when it expires. Validating it is where the security lives: verify the signature, then check iss is the provider you expect, aud is your client id, exp has not passed, and the nonce matches the one you sent. Those are the checks the vulnerable pattern above skips entirely.

The track then covers what makes this workable at scale. Discovery lets a client fetch a provider's configuration rather than hard-coding endpoints, and JWKS publishes the provider's signing keys so that rotation happens without every relying party redeploying — with the caveat that fetching keys by an identifier the token supplies is itself a trust decision. From there, federation and single sign-on assemble from parts you now recognise: one identity provider, many relying parties, a session at the provider that lets a user move between applications without re-authenticating, and the harder question of what should happen to all those applications when that single session ends.