https://www.youtube.com/watch?v=XeFqLDL4lVA
Bearer token. Access token. ID token. Session cookie. OAuth. OIDC. JWT. API key. You open the auth docs and they throw ten words at you.
It feels like ten things. It's four. Here they are.
1. Identity — who you CLAIM to be
Every auth system starts with the same question: who are you? Not yet — who do you claim to be?
That's identity. It's a claim. jane@example.com. User ID 42. service: payments. A string, a number, a subject line. The system has no reason yet to believe you, but you made the claim.
Here's the part most tutorials skip. Identity and proof are two separate things. The email address alone is not authentication. It's just what you told the server.
2. Credential — proof of the claim
A credential is proof the claim is real. Something only you could produce.
- A password that only you know.
- A private key that only you hold.
- A signature from a device only you own.
- Your fingerprint, your face, a code from your authenticator app.
All of those play the same role: proof attached to a claim. When you see "username and password" in one system and "private key and signature" in another, you're looking at the same primitive, wearing different clothes.
API keys are the weird one. An API key is a credential that skips the claim — the key itself IS the identity. Possession equals authentication. The server sees the key, looks it up, and now knows who you are AND that you're allowed to be here. Credential and session, fused into one long-lived string. That's why leaking an API key is catastrophic — there's no second factor. The string is the whole auth system.
Together, identity plus credential answers: "you are who you said you were." Authentication is done. But on the very next request, the server forgets. Unless you give it something to remember.
3. Session — the permit you carry across requests
HTTP has no memory. Every request arrives alone. If the server made you log in on every click, the internet would be unusable.
So after you prove who you are, the server hands you a permit. Something small you can carry. You show it on every subsequent request; the server says "I already know this one" and lets you in.
That permit is a session.
A session isn't a data structure — it's a role. It's the thing that carries your proven identity across requests so you don't re-prove it every single time.
There are two common shapes for that permit. Same role, different geometry:
Shape one — the session cookie. The server stores everything in its database: who you are, what you can do, when this expires. It hands you an opaque ID like sess_k2n9xq. That ID means nothing to you or to anyone else — it's just a ticket stub. The server looks it up in its own memory on every request.
Shape two — the JWT. The server doesn't want to store anything, so it writes everything you need on a piece of paper and signs it with its own secret key. Your identity, your permissions, when this expires — all signed. You carry the paper; the server just verifies the signature. That's a JSON Web Token.
Same primitive, same role. Opaque ID vs. signed claim bag. One requires a database lookup, one does not. And that trade-off is the entire debate behind every "sessions vs. tokens" blog post you've ever skimmed.
Both are sessions. Don't let the vocabulary trick you.
4. Permission — what the session is allowed to DO
The server knows who you are. It knows you've been here recently. But there's one more question before it actually does anything: are you allowed to do this?
That's permission. And it's completely separate from the first three.
Read a user's profile? Maybe. Delete their account? Probably not. Charge their card? Only if you're billing. Permission is what the authenticated you is allowed to do.
Authentication answers "who are you." Authorization answers "what can you do." They're different primitives, use different data, and fail in different ways. If your authentication is broken, random strangers get in. If your authorization is broken, logged-in users access things they shouldn't. Both are breaches. But the fix lives in a completely different part of your code.
So the four primitives split across a gate:
- Identity + Credential on the left — they prove who you are
- Permission on the right — it decides what you can do
- Session straddles the gate — it carries the "who" forward so the "what" can get asked on every request without redoing the proof
The payoff: every scary acronym is these four
Watch what was hiding behind the big words.
"Sign in with Google." That's OAuth — a delegation flow. Instead of your app asking for a password, it sends you to Google. Google authenticates you. Google hands your app a session with a specific permission: "this app can read this person's email address."
Look closely. What did your app receive? A session. A permission. And nothing else.
OAuth gives you three of the four primitives. Session and permission directly; credential was handled by Google. But identity? OAuth alone does NOT tell your app who the user is. You got a permission to access their stuff — you did not get a proof of who they are.
This is the part the internet keeps getting wrong. OAuth by itself is authorization, not authentication.
In 2014, a spec added the missing piece: OIDC (OpenID Connect). OIDC is literally OAuth plus one extra thing — an ID token, a signed JWT saying "this user is jane@example.com."
That's the whole difference. OAuth hands you session + permission. OIDC hands you session + permission + identity. All four primitives accounted for. That's how "Sign in with Google" actually becomes a real login.
Every provider's login button, every enterprise SSO, every federated identity system, is some flavor of this — the four primitives, composed across two parties.
Your homework
Next time you open an auth doc, try this: before you touch a single line of code, read every header, every field, every token name, and label it.
Is this proving identity?
Is this carrying a session?
Is this granting permission?
Once you know which of the four you're looking at, the docs stop being scary. They're just four things in slightly different shapes.
Top comments (0)