Authentication

Establishing who is calling: credentials, sessions, tokens, OAuth and API keys, from the backend's side of the problem rather than the protocol's.

Authentication in a Backend

Turning an untrusted credential into an authenticated principal, once, early, in one place — and nothing more than that.

Q · What is the backend actually doing when it authenticates a request?
Credentials and Password Handling

Store passwords with a slow, salted, purpose-built hash from a maintained library. Everything else in this lesson is a consequence of that sentence.

Q · What does a backend have to do with a password, from the moment it arrives to the moment it is verified?
Session Authentication

The server keeps the state and the client carries an opaque handle. Revocation is a delete; the cost is a lookup on every request.

Q · What does a backend actually hold when a user is "logged in" with a session?
Where Sessions Live

Process memory, a database table, a shared cache or a distributed store — four answers with different scale ceilings and different things that happen when they fail.

Q · Where should session state actually be kept, and what breaks at each choice?
Token Authentication and the Revocation Problem

A self-contained token removes the lookup by carrying its own claims — and removing the lookup is exactly what makes immediate revocation hard. That is the trade, and it is the whole lesson.

Q · What do you give up when a token can be verified without asking anyone?
OAuth and OIDC From the Backend Side

Three roles, two very different tokens, and one rule: use a maintained library, because the parts you would get wrong are the security parts.

Q · What does your backend actually do in an OAuth flow, and which role is it playing?
API Keys

A long-lived secret that identifies an application rather than a person — cheap to verify, easy to leak, and revocable only if you designed for it.

Q · When is a long-lived static key the right credential, and what does it take to run one safely?