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

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

Every auth flow answers one question — who are you? — and the methods differ only in how they answer it. At one end, the server remembers you in its own store. At the other, a third party you both trust does the remembering and hands you a token the server accepts. Everything in between is a trade-off between two properties: statelessness (the server remembers nothing, so it scales) and revocability (the server remembers, so it can kick you out). You cannot have both perfectly — that's the spine of the whole field.

Basic auth: proof on every request

Basic authentication is the simplest end of the spectrum: the client sends base64-encoded username:password in the Authorization header on every single request [2]. The server decodes it, checks the credentials against its store, and either serves or rejects.

Basic's defining trait is that proof is re-sent every time, and that's both its strength (no state, no sessions — fully stateless) and its fatal weakness (base64 is not encryption; the credentials traverse every request). Basic should only ever be used over HTTPS, and even then only for low-risk scenarios or as a fallback. The reason to know Basic is to recognize it and reach for something better.

Sessions: the server remembers

Cookie-based sessions move the proof off the wire [5]. On login, the server creates a session record in its own store (memory, Redis, a database) keyed by a random session ID, and sends that ID to the client in a cookie. On every subsequent request, the browser automatically includes the cookie, the server looks up the session by ID, and identifies the user.

The trade-off is the cleanest illustration of the spine:

• Strength: revocability. Because the server holds the session, deleting it logs the user out instantly. The server is the source of truth.
• Weakness: state. The server has to remember every active session. In a multi-server deployment, sessions have to live in shared storage (Redis) or be sticky to one server, or logout/login breaks.

Cookies also bring two well-known attack classes: CSRF (a malicious site triggers an authenticated request using the victim's cookie) and the awkwardness of cross-origin requests. The session model is battle-tested and right when the server is one trust boundary, but it doesn't scale horizontally for free.

Tokens and JWTs: proof the client carries

Token-based auth inverts the session model: instead of the server remembering, the client carries a signed token that proves who they are [3]. On login, the server issues a token (often a JWT — JSON Web Token); on every request, the client sends it in a header (Authorization: Bearer <token>); the server verifies the token's signature and trusts its claims without any server-side lookup [4].

A JWT has three base64-encoded parts separated by dots — header, payload, signature:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsImV4cCI6MTY5...}.SflKxwRJSMeKKF2QT4fwpMeJ...

The signature is what makes this safe: the server signs the payload with a secret only it knows, so a client can't tamper with the claims (changing sub from 42 to 1) without invalidating the signature. The payload is readable by anyone (base64 is not encryption), so JWTs carry no secrets — just identity claims.

The trade-off flips from sessions:

• Strength: statelessness. No server-side session store. Any server can verify any token. This scales horizontally for free.
• Weakness: revocation. A signed token is valid until its expiry. If I need to log someone out before expiry, I need a server-side blocklist — which reintroduces the very state tokens were meant to avoid. Short token lifetimes plus refresh tokens are the standard mitigation.

JWTs are the modern default for stateless APIs and service-to-service auth, with the caveat that "JWT" is often used carelessly — the token must be signed (HS256 with a shared secret, or RS256 with asymmetric keys), never leave the client unencrypted for sensitive data, and have a sensible expiry.

OpenID: third-party vouching

OpenID (and OpenID Connect, its modern OAuth 2.0-based form) is the far end of the spectrum — you don't verify the user at all; a third party you trust does it for you [6]. The flow: the user is redirected to an identity provider (Google, GitHub, Auth0), authenticates there, and is redirected back with a signed assertion the server accepts because it trusts the provider.

This is "Sign in with Google" — single sign-on (SSO) across sites. The server never sees the password; it receives a verifiable claim ("Google says this is user X") and issues its own session or token. The benefit is delegated trust and UX (users reuse one identity); the cost is dependency on the provider and the complexity of the OAuth/OIDC dance.

OpenID is almost always paired with OAuth 2.0, the authorization protocol — OpenID Connect is technically an identity layer on top of OAuth 2.0. The two are commonly conflated; the rough distinction is that OpenID is about who you are (authentication) and OAuth is about what you can do (authorization).

The decision shape

Putting it together, the choice maps to the trade-off and the deployment:

• One server, simple revocation needs → sessions.
• Stateless API, multiple servers, service-to-service → JWTs.
• "Sign in with Google/X" → OpenID Connect over OAuth 2.0.
• Quick internal tool over HTTPS → Basic (acceptable, not great).

And two rules that cut across all of them: always use HTTPS (any of these is broken without transport encryption), and never store passwords in plaintext — hash them with bcrypt/argon2 (that's a separate set of notes on hashing).

How I use this

The way of thinking — where does proof live, and who vouches — is the whole decision tool. Before I write auth code I answer those two questions and the implementation falls out. For my own stateless, multi-server-friendly APIs I default to short-lived JWTs with refresh tokens; for the portfolio's guestbook-style features I use OAuth via Supabase because "Sign in with Google" is worth more than any custom password flow I'd build. The thing I never do is mix the spectrum carelessly — carrying a session ID in a JWT, or sending Basic over HTTP. The trade-offs only hold if the method is used as designed.

References

[1] roadmap.sh, "Authentication — Backend Roadmap." [Online]. Available: https://roadmap.sh/backend/authentication

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

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

[4] "What is JWT?," Akana. [Online]. Available: https://www.akana.com/blog/what-is-jwt

[5] "Session vs Token Authentication," Section.io. [Online]. Available: https://www.section.io/engineering-education/token-based-vs-session-based-authentication/

[6] "OpenID Connect Protocol," Auth0. [Online]. Available: https://auth0.com/docs/authenticate/protocols/openid-connect-protocol