Mastering Modern Login Mechanisms: Cookies, Sessions, JWT, OAuth2 & SSO

Why a Login Mechanism Is Needed

HTTP is a stateless protocol, so each request is independent and the server cannot identify the user without an explicit authentication mechanism. To know who is accessing the system, whether they are logged in, and what permissions they have, mechanisms such as Cookies, Sessions, Tokens, JWT, OAuth2, Refresh Tokens, blacklists, or SSO are required.

Cookie – Browser‑Side State

Cookie is a small piece of data (max 4 KB) written by the server and automatically sent by the browser on subsequent same‑origin requests.

Workflow

Server returns Set-Cookie: uid=123; HttpOnly Browser stores the cookie

Later requests automatically include

Cookie: uid=123

Main Uses

Store front‑end state such as language preference

Hold a Session ID (credential)

Automatic transmission, suitable for traditional web apps

Drawbacks

Can be read or altered by the user → insecure

Prone to CSRF attacks

Session – Server‑Side User Profile

Session stores user data on the server while the browser only keeps a Session ID.

Login Flow

Pros

Secure (user data stays on the server)

Can force logout by deleting the Session

Cons

Server must store Session state (stateful)

Session synchronization required in clustered environments

Not ideal for large‑scale or micro‑service architectures

Token – Decentralized Credential

A token is a string issued by the server; the client must manually add it to the request header, e.g. Authorization: Bearer <token>.

Characteristics

Independent of Cookies

Not sent automatically → natural CSRF resistance

Fits mobile apps, front‑end/back‑end separation, and cross‑origin scenarios

JWT (JSON Web Token) – Self‑Contained Stateless Token

JWT consists of three Base64URL‑encoded parts: Header.Payload.Signature. The Header declares the signing algorithm, the Payload carries claims such as user ID and expiration, and the Signature protects the token from tampering.

Structure Example

{ "alg":"HS256", "typ":"JWT" }

{ "sub":1, "name":"Tom", "exp":1715600000 }

Authentication Flow

Pros

Stateless – suitable for micro‑services and high concurrency

Easy to extend; no Session sharing required

Works across Web, mobile, and IoT clients

Cons

Cannot be revoked before expiration without additional mechanisms

Token size can be relatively large

Payload is only Base64‑encoded, not encrypted; avoid placing sensitive data

Refresh Token – Solving JWT Revocation

Because a JWT cannot be actively invalidated, a second token with a longer lifespan (Refresh Token) is used to obtain new Access Tokens.

Token Types

Access Token – valid 15–120 minutes, used for each API call

Refresh Token – valid 7–30 days, used to obtain a new Access Token

Process

User logs in and receives both tokens

When the Access Token expires, the client sends the Refresh Token to the token endpoint and receives a new Access Token

If the Refresh Token expires, the user must authenticate again

Benefits

Reduces risk of token leakage

Enables forced logout by revoking the Refresh Token

Improves overall security

JWT Blacklist – Early Revocation Techniques

Option 1: Redis Blacklist (recommended)

SET blacklist:<jti> true EX seconds

Option 2: Token Versioning

Store a tokenVersion for each user and embed the same version in the JWT. Increment the version on logout; mismatched versions render previous tokens invalid.

Option 3: Short‑Lived Access Token + Refresh Token

Common industrial practice that limits the exposure window of the Access Token.

Session vs. JWT – Choosing the Right Approach

Monolithic admin systems → Session

Front‑end/back‑end separation (Web / App) → JWT

Micro‑service architecture → JWT validated at the API gateway

High‑security systems (e.g., banking) → Session with multi‑factor authentication

Need forced logout → Session or JWT with blacklist

Cookie / Token Security Best Practices

Do Not Store Tokens in LocalStorage

LocalStorage is readable by XSS attacks. Prefer HttpOnly cookies or in‑memory variables.

CSRF Protection (required for Session)

When using cookies for Session, enable:

SameSite=Lax (or Strict)

CSRF token in request body or header

Origin validation

Referer validation

JWTs are not automatically sent, so they are naturally CSRF‑resistant.

Prevent Token Hijacking

Transmit tokens only over HTTPS

Optionally bind token to User‑Agent or IP address

Use short token lifetimes

Monitor and alert on abnormal login activity

OAuth 2.0 – Authorization Framework

OAuth 2.0 authorizes third‑party access to user resources; it is not an authentication protocol.

Four Roles

Resource Owner (user)

Client (application)

Authorization Server

Resource Server

Authorization Code Flow (most common)

The client exchanges the authorization code for an access token and then creates its own session (Session or JWT).

OAuth 2.1 – Safer Evolution

OAuth 2.1 removes insecure flows (implicit, password) and enforces HTTPS and PKCE, providing a more secure baseline.

SSO (Single Sign‑On) with OAuth / JWT

SSO enables a single login to be shared across multiple systems. Typical stack:

OAuth 2.0 + OpenID Connect

JWT (ID Token)

CAS

Keycloak

Enterprise‑Level Recommended Login Architecture

Benefits:

Micro‑services delegate authentication to a centralized gateway

Blacklist and token renewal are handled centrally

Solution is secure, extensible, and observable

Final Comparative Table (Key Dimensions)

Cookie : stored in browser, automatically sent, can be revoked, moderate extensibility, suitable for traditional web.

Session : stored on server, sent via cookie, revocable, low extensibility, not ideal for front‑end/back‑end separation.

Token : stored client‑side, not auto‑sent, revocable, high extensibility, very suitable for front‑end/back‑end separation.

JWT : client‑side, not auto‑sent, requires blacklist for revocation, excellent extensibility, best fit for modern apps.

OAuth 2.0 : external authorization service, not auto‑sent, revocation depends on implementation, good extensibility, widely used.

OAuth 2.1 : external, more secure, supports revocation, very good extensibility, recommended.

OpenID Connect : client‑side identity authentication, revocable, very good extensibility, standard for SSO.

Key Takeaways (10 Essential Points)

HTTP is stateless; credentials are required for each request.

Cookies are auto‑sent; Sessions keep user data on the server.

Sessions fit traditional monolithic web apps but not micro‑services.

Tokens are manually transmitted, cross‑origin friendly, and suitable for mobile and SPA architectures.

JWT is the most popular token format; it is stateless and extensible.

JWT cannot be revoked early; use Refresh Tokens or a blacklist.

For front‑end/back‑end separation, JWT is the preferred choice.

In distributed micro‑services, a gateway should validate JWT centrally.

OAuth 2.0 is an authorization framework, not an authentication protocol.

SSO typically combines OAuth 2.0 / OpenID Connect with JWT.