19 — Authentication — A Spectrum of Where Proof Lives and Who You Trust

Six names I used to treat as a menu to memorize — Basic, Session, Token, JWT, OAuth, SSO. Writing them down collapsed them into one model: *they're a spectrum, not a menu, and the two axes that place any strategy on it are where the proof lives and who you trust to vouch for you.* [1]

Every auth flow answers one question — who are you? — and the strategies differ only in how they answer it. At one end you re-prove who you are on every single request. At the other you never prove anything to the app at all; a third party you both trust does it for you. Everything in between is a trade-off between statelessness (the server remembers nothing, so it scales) and revocability (the server remembers, so it can kick you out). That trade-off is the whole spine:

With that spine in place, the six names stop being a list to memorize and start being points on a line.

Basic Auth — you prove it, every time

At the left end is the simplest possible answer: send your username and password with every request [2]. The browser base64-encodes the pair — base64 is just a reversible way to wrap the text into a safe string of characters, not encryption — and stuffs it into an Authorization header on each call:

Authorization: Basic YXZlOnNlY3JldA==

That's it. There's no session, no token, no state — the server checks the credentials afresh each time. I now reach for it only for one-off internal tools or simple API gateways, because the cost is obvious: the password travels on every request, and there's no clean way to revoke one without changing the password. It's the trustless baseline everything else improves on.

Session-based — the server remembers you

The first improvement: stop sending the password. On login the server validates credentials once, then stores a record that says "this user is logged in" and hands back a session ID — an opaque string it keeps in a lookup table [3]. The browser carries that ID in a cookie; on each request the server looks it up and knows who you are.

The mental shift for me was seeing what the server-side store buys you: revocation is trivial. Delete the row, and the session is dead instantly — no waiting for a token to expire, no blacklist to maintain. The cost is the mirror image: every server (or a shared store like Redis) has to consult that table on every request, so horizontal scaling gets harder. It's the classic stateful pattern — easy to control, harder to scale.

Token-based — you carry the proof

Move one step right and the proof changes hands. On login the server issues a token — an unguessable string — that is the proof of who you are [4]. The browser stores it and sends it on each request, but the server doesn't look anything up: if the token is valid, you're in. That's the stateless win — any server, anywhere, can validate you with no shared session store.

The trade-off written plainly: because there's no server-side record, revoking a token before it expires is hard. You either wait it out or maintain a blacklist (which is just sessions with extra steps). Tokens also need safe storage — they're bearer instruments; whoever holds one is you.

JWT — a token that carries its own meaning

JWT (JSON Web Token) is the dominant token shape, and the part I had to get straight is that a JWT is not encrypted secrecy — it's a signed claim [5]. It's three base64 chunks — header, payload, signature — joined by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhdmUifQ.sFlKxwRJSMeKKF2QT4f...
        header              payload              signature

The signature is a value the server computes over the first two parts with a secret key — called an HMAC, or a key-pair signature with RSA/ECDSA. Anyone can read the payload — base64-decode it and the claims (sub, exp, iat, custom ones) are right there. What they can't do is change it: alter a byte and the signature stops matching. That's what "signed, not encrypted" means. The payoff is that the token carries its own metadata, so any service sharing the signing key can trust the claims without a database lookup — microservices love it. The footgun is the same: until exp fires, a JWT is valid, and the payload is public, so it never goes near sensitive data [6].

OAuth — you delegate the trust

The right end of the spectrum answers a different question entirely. Up to here, your server checked the password. OAuth flips it: you stop collecting passwords at all and let a provider you both trust — Google, GitHub, the company IdP (identity provider) — vouch for the user [7]. The flow is a redirected handshake: your app sends the user to the provider, the user logs in there, the provider sends back an authorization grant, and your app exchanges it for an access token. You never see the password.

The thing that clicked: OAuth isn't really "logging in with Google" — it's authorization delegation. The access token represents permission your app was granted to act on the user's behalf against the provider's API. That's why there are scopes, consent screens, and refresh tokens — the machinery is about what your app is allowed to do, not just who the user is. Using it purely as login is a common simplification, but conflating the two muddies the model.

SSO — one login, many apps

Single Sign-On is the organizational expression of the same idea: one trusted identity provider, many relying applications [8]. The user authenticates once with the provider; each app trusts the provider's assertion (often via SAML or OIDC — two standard handshake protocols built on OAuth ideas) and logs them in without ever seeing a password. The difference from generic OAuth is mostly framing — SSO is the goal (one login for the whole suite), and protocols like SAML and OIDC are how it's delivered inside enterprises.

For a small portfolio site like this one, SSO is overkill; "Login with Google" via plain OAuth is the right-sized version of the same trust-delegation idea. The spectrum still tells me why — I'm picking the delegation end because I'd rather trust Google's security team than store my own passwords.

How I use this

The spectrum is now my first cut at any auth decision. I ask two questions: do I need to revoke sessions instantly? (lean left, to session-based) and do I want to avoid storing passwords at all? (jump right, to OAuth). JWT fits when I have multiple services sharing a key and can tolerate eventual expiry. Basic stays in the toolbox for trivial internal gates. Naming the axis — where proof lives, who you trust — turned a six-item menu into a single line I can actually reason along.

References

[1] roadmap.sh, "Authentication Strategies," 2024. [Online]. Available: https://roadmap.sh/frontend/auth-strategies

[2] roadmap.sh, "Basic Authentication," 2024. [Online]. Available: https://roadmap.sh/guides/basic-authentication

[3] roadmap.sh, "Session Based Authentication — Visually Explained," 2024. [Online]. Available: https://roadmap.sh/guides/session-based-authentication-visually-explained

[4] roadmap.sh, "Token Based Authentication," 2024. [Online]. Available: https://roadmap.sh/guides/token-authentication

[5] Auth0, "Introduction to JSON Web Tokens," jwt.io. [Online]. Available: https://jwt.io/introduction

[6] Auth0, "JSON Web Token (JWT) signing algorithms overview," jwt.io. [Online]. Available: https://jwt.io

[7] OAuth.net, "OAuth 2.0 — OAuth," 2024. [Online]. Available: https://www.oauth.com/

[8] roadmap.sh, "SSO — Single Sign On," 2024. [Online]. Available: https://roadmap.sh/guides/sso