Chapter 38·Beginner·8 min read
Authentication Basics: Proving Who a Request Is
A plain-English guide to authentication basics for backend engineers — what authentication is, why HTTP's statelessness makes it necessary, how passwords should be stored, and sessions versus tokens at a glance.
June 30, 2026
Our backend can serve data — but the moment that data is personal, a new question appears on every request: who's asking? Authentication is how a backend answers it. This chapter is the practical foundation; a dedicated guide goes deep on sessions, tokens, OAuth, and more. Here we cover what every backend engineer must know.
Authentication answers "who are you?"
Authentication is verifying identity — confirming a request really comes from who it claims to. Logging in is the familiar case: you prove you're the account owner (usually with a password), and the backend then trusts subsequent requests as you.
Keep it separate from a sibling concept it's constantly confused with:
Why statelessness makes auth necessary
Recall from the HTTP chapter that HTTP is stateless — the server forgets you between requests. That's the whole reason authentication is an ongoing concern rather than a one-time gate.
You log in once, but the next request arrives with the server remembering nothing. So every request has to carry proof of who you are. Authentication isn't just the login screen; it's the machinery that re-establishes your identity on each otherwise-anonymous request.
Never store passwords in plain text
The one security rule no backend engineer may get wrong: passwords are never stored as plain text. They're stored as hashes — the output of a one-way function that's easy to compute forward and effectively impossible to reverse.
At login, you hash the submitted password and compare it to the stored hash; you never need the original. The reason is brutal and simple:
Sessions vs tokens: the two approaches
Once a user proves identity, how does the backend remember them across the stateless requests that follow? Two broad approaches, which the auth guide explores in depth:
| Session-based | Token-based | |
|---|---|---|
| Where state lives | On the server (a session store) | In the token itself (self-contained) |
| What the client holds | A session ID | A signed token |
| Server lookup per request | Yes — look up the session | No — verify the token's signature |
| Easy to revoke? | Yes | Harder |
Both work by handing the client a credential at login that rides along on each subsequent request — a session ID stored in a cookie, or a token like a JWT. The trade-offs between them (server lookups, revocation, scaling) are a recurring theme worth understanding well.
Don't roll your own
A closing warning that's really the most important takeaway: authentication is where security incidents concentrate, and it's deceptively easy to get subtly wrong. Password handling, session management, token validation, timing attacks — each has well-known pitfalls and well-tested solutions.
So lean on proven libraries and established protocols rather than inventing your own scheme. "I built a custom auth system" is a phrase that precedes a lot of breaches. Understand the concepts deeply — that's what the full authentication guide is for — but implement with battle-tested tools.
Recap
- Authentication verifies identity — it answers who are you? before the backend trusts a request.
- HTTP's statelessness is why it's needed continuously: every request must re-prove who you are.
- Never store plain passwords — store one-way hashes with a purpose-built password hashing function.
- Sessions keep state on the server; tokens are self-contained — each with trade-offs in lookups and revocation.
- Auth is high-stakes — use proven protocols and libraries; don't invent your own.
Knowing who a request is comes first. Next is deciding what they're allowed to do — that's authorization. Continue to Authorization Explained.