JWT vs Session vs Cookies Explained
- Welcome to Part 5 of the Authentication & Identity Security series.
- This article explains the difference between JWT, Sessions and Cookies.
- Designed for Middleware, DevOps, Cloud, API, and Application Support Engineers.
- Includes enterprise examples using WebSphere, JBoss, Tomcat, Docker, Azure Entra ID, APIs, and Load Balancers.
Introduction
In previous parts, we learned about sessions, cookies, JSESSIONID, stateful applications, stateless applications, and JWT-based authentication.
Now it is important to clearly understand the difference between Cookies, Sessions and JWT. Many engineers confuse these terms and use them interchangeably, but they are different concepts.
Simple Understanding:
A cookie is stored in the browser. A session is stored on the server. A JWT is a signed token usually used for stateless authentication.
What is a Cookie?
A cookie is a small piece of data stored in the user's browser. The server sends a cookie to the browser, and the browser sends it back with future requests.
Cookies are commonly used to store identifiers, preferences, tracking values, and session IDs.
Example Cookie
Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; Secure; HttpOnly
Browser Sends Cookie Back
GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789
Important:
A cookie is only a storage mechanism in the browser. It is not the same as a session.
What is a Session?
A session is server-side storage used to maintain user information after login.
In Java enterprise applications, the session is commonly identified using JSESSIONID.
Session Data Example
Session ID: ABC123XYZ789
Stored on Server:
- userId = pradeep
- role = admin
- loginTime = 10:30 AM
- applicationAccess = policy-portal
The browser does not usually store this full session data. The browser only stores the JSESSIONID cookie. The actual session data remains inside the application server memory or external session store.
Common Platforms
- IBM WebSphere Application Server
- WebSphere Liberty
- Apache Tomcat
- JBoss EAP
- WildFly
What is JWT?
JWT stands for JSON Web Token. It is a signed token that contains claims about the user or application.
JWT is commonly used in APIs, microservices, mobile applications, Docker-based applications, and cloud-native systems.
JWT Example
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJwcmFkZWVwIiwicm9sZSI6ImFkbWluIn0.
signature
JWT Payload Example
{
"sub": "pradeep",
"role": "admin",
"iss": "https://login.company.com",
"aud": "api.company.com",
"exp": 1789459200
}
Important:
JWT payload is encoded, not encrypted by default. Do not store passwords, secrets, or sensitive data inside JWT.
Cookie, Session and JWT Flow
Session + Cookie Flow
User Login
│
Application Server Authenticates User
│
Server Creates Session
│
Server Generates JSESSIONID
│
Browser Stores JSESSIONID Cookie
│
Browser Sends Cookie With Every Request
│
Server Finds Session Using JSESSIONID
JWT Flow
User Login
│
Authentication Server Validates User
│
JWT Generated
│
Client Stores JWT
│
Client Sends JWT With API Request
│
API Validates JWT Signature and Expiry
│
Access Granted
JWT vs Session vs Cookies Comparison
| Feature |
Cookie |
Session |
JWT |
| Basic Meaning |
Browser storage mechanism |
Server-side user state |
Signed authentication token |
| Stored In |
Browser |
Application Server / External Store |
Client side |
| Common Example |
JSESSIONID cookie |
User session in JVM heap |
Bearer token |
| Stateful / Stateless |
Storage only |
Stateful |
Stateless |
| Server Memory Required |
No |
Yes, unless externalized |
No session memory required |
| Scaling |
Easy |
Requires sticky session or replication |
Easier horizontal scaling |
| Best For |
Session ID, preferences |
Traditional web applications |
APIs, mobile apps, microservices |
| Security Risk |
Cookie theft |
Session hijacking |
Token theft |
Enterprise Middleware Example
Traditional WebSphere / JBoss / Tomcat Application
Browser
│
JSESSIONID Cookie
│
IBM HTTP Server / NGINX
│
WebSphere / JBoss / Tomcat
│
Session Stored in JVM Memory
This architecture is common in enterprise web applications. The application server stores session data and the browser stores only the JSESSIONID.
Common Requirements
- Session timeout configuration
- Sticky session at load balancer
- Session replication in cluster
- Secure and HttpOnly cookie flags
- Logout session invalidation
Docker and Cloud Perspective
Docker does not automatically make an application stateless. If the application running inside the container stores sessions in JVM memory, it is still stateful.
Stateful Docker Application
Browser
│
JSESSIONID Cookie
│
Docker Container
│
Tomcat / JBoss / WebSphere Liberty
│
Session Stored in Container JVM Memory
If the container restarts or is replaced, in-memory sessions may be lost.
Better Cloud-Native Options
- Use JWT-based stateless authentication
- Use Redis as external session store
- Use database-backed session persistence
- Use short-lived tokens with refresh tokens
- Use API Gateway for centralized token validation
Azure Entra ID Perspective
Azure Entra ID commonly issues tokens for modern enterprise applications and APIs.
User
│
Application
│
Azure Entra ID Login
│
Access Token / ID Token
│
Application or API Access
In this model, Azure Entra ID handles authentication and issues tokens. Applications validate the token before granting access.
Enterprise Use Case:
Azure Entra ID + OAuth2/OIDC + JWT is commonly used for SSO, API authentication, Azure applications, and cloud-native platforms.
Which One Should You Use?
| Application Type |
Recommended Approach |
| Traditional WebSphere / JBoss / Tomcat web app |
Session + Cookie |
| REST API |
JWT / OAuth2 Access Token |
| Docker-based application |
JWT or Redis-backed session |
| Single Page Application |
OIDC with secure token handling |
| Enterprise SSO |
Azure Entra ID / SAML / OIDC |
| Legacy Java application |
Session-based authentication |
Common Misconceptions
Misconception 1: Cookie and Session are Same
This is incorrect. A cookie is stored in the browser. A session is stored on the server.
Misconception 2: JWT Always Replaces Session
JWT is useful for APIs and stateless architectures, but traditional web applications may still use sessions effectively.
Misconception 3: JWT is Always More Secure
JWT security depends on implementation. Poor token storage, long expiry, missing validation, or weak signing keys can create serious risks.
Misconception 4: Docker Makes Applications Stateless
Docker only packages and runs applications. If the application stores sessions in memory, it remains stateful.
Security Best Practices
Cookie Best Practices
- Use Secure flag for HTTPS-only transmission.
- Use HttpOnly flag to reduce JavaScript access.
- Use SameSite attribute to reduce CSRF risk.
- Set proper cookie path and domain.
Session Best Practices
- Configure proper session timeout.
- Invalidate session after logout.
- Regenerate session ID after login.
- Use session replication or external session store for HA.
- Avoid storing unnecessary large objects in session.
JWT Best Practices
- Use HTTPS for all token communication.
- Keep access tokens short-lived.
- Validate signature, expiry, issuer, and audience.
- Never store passwords or secrets in JWT payload.
- Use refresh tokens carefully.
- Rotate signing keys periodically.
Common Production Issues
| Issue |
Possible Cause |
| User logged out randomly |
Session timeout, server restart, or sticky session issue |
| Session works on one node but fails on another |
No session replication or affinity |
| JWT gives 401 Unauthorized |
Expired token, invalid signature, wrong audience or issuer |
| Cookie not sent to server |
Wrong domain, path, Secure flag, or SameSite setting |
| High JVM memory usage |
Too many sessions or large session objects |
| Login loop |
Cookie, SSO, reverse proxy, or token validation issue |
Key Takeaways
- A cookie is browser-side storage.
- A session stores user data on the server.
- JSESSIONID is commonly stored inside a cookie.
- JWT is a signed token used for stateless authentication.
- Sessions are common in WebSphere, JBoss, and Tomcat applications.
- JWT is common in APIs, Docker applications, microservices, and cloud-native systems.
- Cookies, sessions, and JWT can all be secure or insecure depending on implementation.
What’s Next?
Next Article:
Part 6 – API Authentication & API Gateway Security
In the next article, we will understand API authentication methods such as API keys, Basic Authentication, JWT, OAuth2, and how API Gateways secure backend services.
Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog:
MiddlewareBox.com
