Authentication: The Lock on Every Door
Every door you have met so far assumed the system trusts whoever is knocking. In the real world it cannot. This lesson is the lock: how a system proves who you are, decides what you may do, and carries the answer on every request.
Every door from the last lessons has a lock. Send the same request three ways — no key, a key, and a key that isn't allowed here — and the server's three answers teach you everything.
By the end of this lesson
You'll know the difference between authentication and authorization, how API keys and OAuth tokens work, what 401 and 403 really mean, and the one habit that prevents most security trouble.
Two different questions hide inside the word “access.” Authentication asks who are you? Authorization asks what are you allowed to do? They're genuinely separate, and an API answers them with different status codes — which is the clearest way to finally keep them straight. Watch the same account endpoint respond to three requests:
The 401 and the 403 look similar but mean opposite things. 401 is “I don't know you.” 403 is “I know you perfectly well, and the answer is still no.” Reading them correctly is half of debugging access problems.
The credential: keys and tokens
What turns the 401 into a 200 is the line in the middle. The simplest credential is an API key — a long secret string you send on every request, usually in an Authorization: Bearer <token> header. Think of it as a password for software: anyone holding it is you, as far as the server can tell. That's exactly why a key belongs in an environment variable, never pasted into your code or committed to a repository.
When some other app needs access to your data without you handing over your actual password, the standard is OAuth 2.0 (defined in RFC 6749). Instead of your password, it issues a scoped, revocable token: “this app may read your calendar, nothing else, until you say stop.” That word — scope — is precisely what separates the 200 from the 403 above. The token in the 403 case was valid; it just wasn't scoped to delete.
Who you are gets you in the door. Scope decides which rooms you enter.
The one habit that matters
Give out the least access a thing needs, and nothing more. Most security trouble I've seen came from a credential with far more reach than its job required — a key that could write when it only ever needed to read, or one scoped to everything when it touched one thing. Treat every key like the password it is, lean on scopes, and a leaked credential becomes a contained problem instead of a catastrophe.
Sources — IETF, RFC 6749 — The OAuth 2.0 Authorization Framework and oauth.net; MDN, HTTP authentication.
0
Tap to appreciate
Was this chapter helpful?