Don’t Panic — OpenID Connect

OpenID Connect is what happens when an application prefers to verify a sign-in result instead of keeping a password. It builds on OAuth two point zero, which is about delegated access. OIDC adds the identity layer, so the application can know who authenticated. The password stays with the authentication service, where it can continue being somebody else’s problem.

The two names to keep are Relying Party and OpenID Provider. The RP is the application. The OP is the service that authenticates the person. The browser visits the OP and returns to the RP with a short-lived code. The code is the courier, not the treasure, so the RP exchanges it at the token endpoint instead of leaving tokens in the browser redirect.

An ID Token is the signed authentication result. It is not a general admit-one pass for every API. The RP checks the trusted issuer, its own audience, the signature, the lifetime, and the nonce when it sent one. Decoding it only reads the label on the wrapper; validation checks whether the entire parcel belongs here.

The surprise is that a login has several clocks. The OP session, the application local session, an ID Token, and an access token can all end at different times. Logout is coordination, not a magic undo button. That is why an application must end its own local session even when the OP offers a logout endpoint.

If the variables are starting to swarm, keep a short chant. Trust an issuer. Correlate the request. Validate the ID Token. Map issuer and subject. Then create a local session and apply local policy. The Intro explains the flow in detail. The Slides map the boundaries. The Cheatsheet keeps the validation order and failure map. Field Notes cover the parts that tend to bite in production.

Don’t Panic — OpenID Connect

Relevant careers