How web identity actually works — authentication vs authorization, OAuth 2.0 and its flows, tokens and JWTs, OpenID Connect, SAML enterprise SSO, sessions and single sign-on, and securing identity in practice.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words that sound alike and mean opposite things. Authentication asks "who are you?"; authorization asks "what are you allowed to do?" Every protocol in this series exists to answer one or the other, and mixing them up is how you build systems that are both insecure and broken.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words: authentication asks 'who are you?', authorization asks 'what are you allowed to do?' Every protocol in this series answers one or the other.
OAuth solved a specific, once-terrible problem: how does an app access your data on another service without you handing over your password? Its answer — a scoped, revocable token granted through a trusted intermediary — is elegant, but only if you remember what OAuth actually is. It's authorization, not login, and everything about it makes sense once you hold that firmly.
OAuth solved a once-terrible problem: how does an app access your data on another service without your password? Its answer — a scoped, revocable token through a trusted intermediary — is elegant, but only if you remember it's authorization, not login.
OAuth isn't one procedure — it's a family of flows for different kinds of clients, and picking the wrong one is a security bug, not a style choice. The good news is that modern guidance has collapsed the confusion: for almost every case today, the answer is the authorization code flow with PKCE, and knowing why the alternatives were deprecated is knowing OAuth security.
OAuth isn't one procedure — it's a family of flows for different clients, and picking the wrong one is a security bug. Modern guidance collapsed the confusion: for almost every case, the answer is the authorization code flow with PKCE.
Tokens are the currency of modern identity — they carry proof of authorization and identity across every request. But "token" hides real distinctions: access versus refresh versus ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
Tokens are the currency of modern identity — access, refresh, and ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
Everyone kept using OAuth to log users in, and everyone kept doing it slightly wrong, because OAuth was never designed to answer "who is this user?" OpenID Connect is the fix: a thin, standardized authentication layer on top of OAuth that adds one crucial thing — an ID token that securely tells you who the user is. It's what "Sign in with Google" actually runs on.
Everyone kept using OAuth to log users in, and kept doing it slightly wrong, because OAuth was never designed to answer 'who is this user?' OpenID Connect is the fix: a thin authentication layer on OAuth that adds an ID token. It's what 'Sign in with…' runs on.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity, because the corporate world standardized on it a decade before OIDC existed and enterprise software moves slowly. If you build anything sold to businesses, you will meet SAML, and understanding it as "the same federated-login idea as OIDC, different machinery" is what makes it approachable.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity. If you build anything sold to businesses you will meet SAML, and understanding it as 'the same federated-login idea as OIDC, different machinery' makes it approachable.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Sessions bridge stateless requests into a continuous identity, single sign-on shares that identity across apps, and single logout is a genuinely hard problem that most systems get partly wrong.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Single logout is a genuinely hard problem that most systems get partly wrong.
Identity is the front door to everything, which makes it the most attacked part of most systems and the place where a single mistake compromises everyone. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and doing yourself what a library should do. This closing post is the practical security checklist.
Identity is the front door to everything, which makes it the most attacked part of most systems. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and rolling your own.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.