Session-based auth vs JWT

Session-based auth keeps identity and state on the server (or in a shared store); the client sends a session ID (cookie). JWT (JSON Web Token) puts claims (e.g. user id, roles) in a signed token; the client sends the token and the server verifies the signature without storing session state.

Session flow

sequenceDiagram participant C as Client participant S as Server participant Store as Session Store C->>S: Login (user, password) S->>S: Verify credentials S->>Store: Create session(sessionId, user data) S-->>C: Set-Cookie: sessionId Note over C,S: Later requests C->>S: Cookie: sessionId S->>Store: Get session(sessionId) Store-->>S: User data S-->>C: Response

JWT flow

sequenceDiagram participant C as Client participant S as Server C->>S: Login (user, password) S->>S: Verify credentials S->>S: Sign JWT (payload: userId, roles, exp) S-->>C: { access_token: "jwt..." } Note over C,S: Later requests C->>S: Authorization: Bearer <jwt> S->>S: Verify signature, check exp (no DB lookup) S-->>C: Response

Aspect	Session	JWT
State	Server/store holds session	Stateless (token is self-contained)
Revocation	Delete session = instant logout	Hard until expiry; need blacklist or short TTL
Scaling	Need shared store or sticky sessions	Any server can verify token
Size	Cookie = small ID	Token can be large (claims in payload)
Use case	Web apps with server-rendered pages	APIs, SPAs, mobile, microservices

Use sessions when you need instant logout and control server-side. Use JWT when you want stateless APIs, multiple services verifying the same token, or short-lived access tokens with refresh tokens for revocation.