Sessions, Cookies, JWTs, Tokens, SSO, and OAuth 2.0

These terms often get bundled together, but they solve different parts of identity and access. The easiest way to stay clear is to separate how the browser stores state, how the server proves identity, and how systems delegate access.

Cookie is just a browser storage mechanism

A cookie is a small piece of data the server asks the browser to store and send back on later requests. A cookie is not automatically a login system. It is just a transport and storage mechanism.

Cookies are commonly used for session identifiers because browsers send them automatically for matching domains. Security attributes such as HttpOnly, Secure, and SameSite matter because they reduce theft and cross-site misuse.

Session means the server keeps the login state

With session-based authentication, the server stores login state in server-side storage and gives the browser a session ID, usually inside a cookie. On each request, the server looks up that session ID and recovers the user identity.

The strength of this model is control. Sessions can be revoked centrally and can hold additional server-managed state. The weakness is operational: the server now depends on shared session storage or sticky routing if many application instances are involved.

Token is the broader category

A token is any value that represents identity or permission. It might be opaque, meaning the client cannot interpret it, or self-contained, meaning it carries claims directly. Saying “token auth” without more detail is incomplete because tokens come in different forms.

JWT is one token format

A JWT, or JSON Web Token, is a structured token format with claims encoded as JSON and protected by a signature, and sometimes encryption in related standards. The signature proves that the token was issued by a trusted party and was not modified.

JWTs are useful when many services need to verify identity locally without calling a central session store on every request. The tradeoff is revocation. Once issued, a JWT is usually valid until expiry unless extra revocation machinery exists.

SSO centralises authentication

Single sign-on means users authenticate once with a central identity provider and can then access multiple applications. SSO is a user experience and trust arrangement, not a token format by itself. Under the hood, SSO systems often use protocols such as SAML or OpenID Connect.

The benefit is reduced password sprawl and central policy enforcement. The cost is that the identity provider becomes a critical dependency.

OAuth 2.0 delegates access

OAuth 2.0 is mainly an authorisation framework. It lets one application obtain limited access to a user’s resources on another service without learning the user’s password. That is why “Sign in with X” and “Allow this app to read your calendar” are related but not identical outcomes.

OAuth defines roles, scopes, and grant flows. OpenID Connect is the layer commonly added on top when the goal is authentication about the user identity as well.

How they fit together

A user might log in through SSO, receive an ID token or session, store the browser state in a cookie, and grant a third-party application OAuth access to some protected API. Those are not competing ideas. They are pieces at different layers.

Understanding that separation is what makes identity architecture much easier to reason about.