07 — Authentication: Who Is Calling?

"Add a login" used to mean one thing to me until I saw three very different clients — a script, a browser app, a third party — each needing a different proof of identity. The model that finally clicked: every authentication method is a different way to carry and verify a proof of identity, and the choice is driven by who the client is and how much complexity they can bear. [1] A script calling an internal API, a browser app with a logged-in user, and a third-party asking to act on a user's behalf are three very different problems, and the methods exist because no single one fits all three.

The thread connecting these methods is a tradeoff curve: simplicity on one end, delegated trust on the other. Basic Auth is trivially simple and weak. Sessions add server-side memory. Tokens move the proof to the client. JWTs make the proof self-verifying. OAuth 2.0 delegates the identity check to someone the user already trusts. OIDC adds "and here's who they are" on top of OAuth's "and here's what you may do." Each step adds power and complexity.

Authentication vs. authorization

One distinction I had to nail down before any of this made sense: authentication asks "who are you"; authorization asks "what are you allowed to do." This post is about the first. The methods here prove identity; the next post in the series covers the access-control models that decide what an authenticated caller may then touch. OAuth 2.0 straddles the line — it's technically an authorization framework — which is exactly why OIDC exists as a separate identity layer on top of it.

Basic Auth: the simplest, weakest

Basic Authentication sends the username and password on every request, base64-encoded in the Authorization header [2]:

Authorization: Basic dXNlcjpwYXNzd29yZA==

The thing to internalize: base64 is encoding, not encryption. [2] Anyone who intercepts the request reads the credentials instantly. Basic Auth is only acceptable over HTTPS, and even then it's weak because the raw password is sent on every call. It's fine for quick internal scripts or dev APIs, and unacceptable for anything public-facing. I treat Basic Auth as "the one you reach for when simplicity is the only priority and the channel is already trusted and encrypted."

Session-based auth: the server remembers

Session-based authentication is the classic web model: the user logs in once with credentials, the server creates a session and stores it server-side, and the session ID travels in a cookie on every subsequent request [3]. The server looks up the session to identify the caller.

The tradeoff is server-side state. Every authenticated request hits the session store, which means sessions don't scale across servers without shared storage (Redis, a database). Sessions are a natural fit for rendered web apps where the browser handles cookies automatically, and a poor fit for mobile or third-party clients where cookie semantics and CSRF concerns get awkward. The model I hold: sessions optimize for "the server is in charge of remembering"; tokens (next) optimize for "the client carries the proof."

Token-based auth: the client carries the proof

Token-based authentication flips the storage: after login, the server issues a token (an opaque string or a JWT), and the client includes it in the Authorization header of every request [4]. The server verifies the token instead of looking up a session.

Authorization: Bearer eyJhbGciOi...

Two properties make tokens attractive. They're stateless — the server can verify them without a session store, which scales horizontally. And they're client-agnostic — a mobile app, a SPA, and a service-to-service call all use the same Bearer header pattern, no cookies required. The cost is that you now own token issuance, expiration, and revocation, none of which a session store handled for you.

JWT: a self-verifying token

A JSON Web Token (JWT) is a specific, popular token format — a compact, URL-safe string with three base64-encoded parts separated by dots [5]:

eyJhbGciOi... . eyJzdWIiOi... . SflKxwRJSm...
   header            payload        signature

• Header — the algorithm used to sign.
• Payload — claims about the caller (user ID, roles, expiry).
• Signature — the server's cryptographic signature over header+payload.

The signature is the clever part: because the server signed it, any server with the verification key can confirm the token is genuine and untampered without a database lookup [5]. That's what makes JWTs stateless. The catches I watch for: JWTs are unreadable once issued (you can't easily revoke one before its exp), so keep expiries short and use refresh tokens for long sessions. And never put secrets in the payload — it's only base64-encoded, not encrypted; anyone who holds the token can read it.

OAuth 2.0: delegated authorization

OAuth 2.0 solves a different problem: letting a third-party app act on a user's behalf without the user giving that app their password. [6] When you "connect" an app to your GitHub account, that's OAuth 2.0. The user authenticates with the provider (GitHub), and the provider issues the third-party an access token scoped to specific permissions — never the user's password.

OAuth defines four roles: the resource owner (the user), the client (the third-party app), the authorization server (issues tokens), and the resource server (your API, validates tokens). The flows (Authorization Code, Client Credentials, etc.) are how tokens get issued for different scenarios. The reason OAuth matters for API design: it's the standard way to let other apps call your API on behalf of users without the security catastrophe of password sharing.

OIDC: identity on top of OAuth

Here's the subtlety that used to confuse me: OAuth 2.0 is authorization, not authentication. It answers "may this app do X," not "who is the user." OpenID Connect (OIDC) is the thin identity layer added on top of OAuth 2.0 to answer the second question [7]. OIDC introduces an ID token — a signed JWT containing claims about the authenticated user (name, email, sub).

OIDC is the standard behind "Sign in with Google / GitHub / Apple." When you see that button, you're using OIDC: the provider authenticates the user, returns an ID token proving who they are, and your API trusts that proof because it's signed by a provider you configured. The rule I use: if my API needs to verify identity (login), it's OIDC; if it only needs to grant access (a token to call an API), plain OAuth 2.0 suffices. Most real systems end up with both.

How I use this

The choice is a matrix of "who is the client." Internal script or dev tool over HTTPS — Basic Auth is tolerable. First-party browser app with rendered pages — sessions. Mobile app, SPA, or service-to-service — bearer tokens, usually JWTs. Third-party apps acting on a user's behalf — OAuth 2.0. "Sign in with X" or any federated login — OIDC on top of OAuth 2.0. The mistake I try to avoid is using one method for every situation — putting raw Basic Auth on a public API, or reaching for full OAuth when a simple JWT would do. Each method optimizes for a specific client and threat model; the work is matching them.

References

[1] Postman, "API Authentication," 2024. [Online]. Available: https://www.postman.com/api-platform/api-authentication/

[2] Swagger, "Basic Authentication," 2024. [Online]. Available: https://swagger.io/docs/specification/authentication/basic-authentication/

[3] Authgear, "Session vs Token Authentication," 2024. [Online]. Available: https://www.authgear.com/post/session-vs-token-authentication

[4] Okta, "What Is Token-Based Authentication?," 2024. [Online]. Available: https://www.okta.com/uk/identity-101/what-is-token-based-authentication/

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

[6] auth0, "What is OAuth 2.0?," 2024. [Online]. Available: https://auth0.com/intro-to-iam/what-is-oauth-2

[7] Fortinet, "OIDC: Simplifying Secure Authentication With OpenID Connect," 2024. [Online]. Available: https://www.fortinet.com/resources/cyberglossary/oidc