Sessions, JWT, OAuth2 or SSO: When to Use Each

0:00The Stranger Problem

Every request you send to a server arrives as a total stranger. HTTP has no memory. You logged in three seconds ago — the server has already forgotten. So every app you have ever used has to solve the same problem: how do you prove who you are, on every single click, without typing your password every time? There are four classic answers — sessions, tokens, delegation, and single sign-on. Pick the right one, and you never think about it again. Pick the wrong one, and you will be rebuilding your login system in a year. Here is how to choose.

0:34Sessions — The Coat Check

The oldest answer: the server just remembers you. You log in once, the server writes a record — a session — and hands your browser a claim ticket. A cookie, carrying nothing but a long random ID. From then on, every request shows the ticket, and the server looks you up. The power move here is control. The session lives on the server, so the server can end it. Click log out, and the ticket is worthless instantly. The cost is that memory. Every request means a lookup, and when you grow to many servers, they all need to share it. When to use it: one app, one backend, rendered on the server — and any time instant revocation matters more than raw scale.

1:18JWT — The Signed Passport

The second answer flips it. What if the server did not have to remember? A JSON Web Token takes what the server knows about you — your ID, your role, an expiry — and signs it. Now the state travels with you, like a passport. Any server can check the signature and trust the contents. No lookup, no shared memory. That is why APIs and microservices love it. But the passport has a dark side: it cannot be un-issued. If a token is stolen, it stays valid until it expires. The standard defense is short lives — access tokens that live for minutes, not months, quietly refreshed in the background. When to use it: many services, mobile clients, scale — when you can trade instant revocation for speed.

2:09OAuth2 — The Valet Key

The third answer solves a different problem entirely — and it is the most misunderstood. OAuth is not about proving who you are. It is about lending out slices of your account. When an app wants to read your calendar, it does not ask for your password. It sends you to Google, you approve one narrow permission, and the app gets a scoped token — a valet key. It can park the car. It cannot open the trunk. And every Sign in with Google button is this same machinery with an identity layer bolted on top, called OpenID Connect. When to use it: any time a third party needs a piece of someone's account — and never as a password collector.

2:56SSO — One Key, Every Door

The fourth answer is for fleets. A company does not want fifty logins for fifty tools — it wants one identity provider that every app trusts. That is single sign-on. You sign in once, at the front door. After that, each app just asks the provider: is this person good? And the session that matters lives there. The killer feature is not convenience — it is the exit. When someone leaves the company, IT disables one account, and every door locks at once. When to use it: more than a handful of internal apps, or the day your first enterprise customer asks for it. And they will ask.

3:39The Stack

So — which one do you pick? Here is the framework. One server-rendered app: sessions. Many services and API clients: tokens. Touching someone else's data: OAuth. A fleet of apps and one workforce: single sign-on. But here is the twist. Watch what actually happens when you log into a serious product. You hit the app, it bounces you to an identity provider — that is single sign-on. The handshake between them runs on OAuth machinery. The provider recognizes you because of its own session cookie. And what lands back in your app is a signed token. All four answers, in one login, doing the one job each is best at. They were never competitors. They are layers.