The topic of Auth: It's Easier Than You Think is currently the subject of lively debate — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
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.
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.
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.
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.
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.
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.
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?
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.
"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.
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.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
For further actions, you may consider blocking this person and/or reporting abuse
DEV Community — A space to discuss and keep up software development and manage your software career
Built on Forem — the open source software that powers DEV and other inclusive communities.
Why it matters
News like this often changes audience expectations and competitors’ plans.
When one player makes a move, others usually react — it is worth reading the event in context.
What to look out for next
The full picture will become clear in time, but the headline already shows the dynamics of the industry.
Further statements and user reactions will add to the story.