Member-only story
OAuth and OIDC: The Flow You Should Use and the Token You Should Not Trust
Hi everyone, welcome back. Today, I will be going over OAuth and OIDC — the delegated authorization protocol that lets an application act on a user’s behalf without holding their password, the identity layer built on top of it, and how to use both correctly.
Here is the frame I would keep in mind throughout. OAuth is a protocol for proving that a request was authorized, and almost every real-world OAuth vulnerability comes from trusting something the protocol never promised: a code never bound to a verifier, a redirect URI only prefix-matched, an ID token used as an API credential, a signature treated as an audience check. Those are the ordinary failure modes, and one flow plus one validation discipline eliminates most of them.
The Vocabulary, First
If you are newer to this, here is the small vocabulary the specifications use, because most confusion around OAuth is vocabulary confusion rather than protocol confusion.
- Resource owner — the human who owns the data, usually the user at the browser.
- Client — the application wanting access. Not necessarily a frontend; a backend calling someone else’s API is a client.
- Authorization server — authenticates the resource owner, collects…
