Authentication Over HTTP

Let’s start with an uncomfortable truth.

HTTP was never designed for authentication. It doesn’t know who you are. It doesn’t remember what you did. It doesn’t even know if two requests came from the same person.

And yet…, You log in. You stay logged in. You log out. Your identity persists across requests. That should feel strange. Because authentication over HTTP is not natural. It’s a carefully engineered workaround.

Why Authentication Feels So Awkward in HTTP

HTTP treats every request like a stranger. No memory. No history. No concept of “this user”.

Authentication, on the other hand, is all about continuity:

• This request comes from the same user as before

• This user has certain permissions

• This identity should be trusted

These two ideas don’t fit neatly together. So instead of changing HTTP, we adapted around it.

The Core Rule HTTP Refuses to Break

Before going further, lock this in: HTTP will not remember you.

Not because it’s lazy. Because remembering would break:

• Scalability

• Load balancing

• Failure recovery

So authentication had to follow one rule: If identity exists, it must travel with the request.

That single rule explains almost every auth mechanism on the web.

The First Big Trick: Proving Identity Every Time

In a traditional conversation, you prove who you are once. In HTTP, you prove it on every request.

That proof might be: A cookie, A token, A header, A signature.

But the idea is always the same: “Here is evidence that I am who I say I am.”

The server verifies it. Processes the request. Then forgets everything again.

Cookies: Not State, Just a Delivery Mechanism

Cookies are often misunderstood. They don’t make HTTP stateful. They don’t store server memory.

Cookies are just: “Data the client automatically sends back.” That’s it.

The server doesn’t remember the client. The client remembers for the server.

This is a recurring pattern in HTTP: Memory exists, But it lives outside the server.

Sessions Without Stateful Servers

This is where confusion usually starts. People hear “session” and think: Server memory, Sticky sessions, One user tied to one machine.

That’s not required. A session is just: “An authenticated context with a lifecycle.”

That context can be: Stored in a database, Stored in Redis, Encoded inside a token, Split across client and server. HTTP doesn’t care. As long as the server can verify the request independently, statelessness remains intact.

Tokens: Moving Identity Into the Request

Tokens push the idea even further. Instead of: “Here’s an ID, look it up”

Tokens say: “Here’s my identity and claims, cryptographically signed”

Now the request carries: Who the user is, What they’re allowed to do, When this proof expires.

The server verifies the signature and moves on. No memory required.

Why Access Tokens Expire So Quickly

This often confuses people. If tokens are stateless, why expire them?

Because: Tokens can be stolen, Tokens can leak, Tokens cannot be “forgotten” by the server.

Expiration is damage control. Short-lived access tokens reduce blast radius. Long-lived refresh tokens handle continuity.

This split is not accidental. It’s defensive design.

Refresh Tokens: Controlled State

Refresh tokens introduce intentional state.

They are: Stored securely, Revocable, Checked against server records.

This is where systems reintroduce control without breaking HTTP.

HTTP stays stateless. Auth regains control. Balance restored.

Logout: The Strangest Part of All

Here’s the weirdest question: How do you “log out” of something that never remembers you?

You don’t. You invalidate the proof. Logout means: Tokens are revoked, Cookies are cleared, Future requests fail verification.

Nothing is “ended” inside HTTP. The server just stops accepting the proof.

That’s why logout feels indirect. Because it is.

Why Authentication Still Works Despite All This

At this point, auth might feel like duct tape.

But it works because: Identity is explicit, Verification is local, Requests are self-contained, Servers remain replaceable.

Auth doesn’t fight HTTP. It adapts to it. That’s why the web scales.

What Comes Next

In the next one we will look into Authorization: Who Can Do What (And Why It’s Separate From Auth)

This article is part of the Thinking in Backend series, where we learn backend engineering by focusing on how systems think, not just how code runs.