Session
A temporary interaction between a user and a web application that maintains state across multiple requests within a defined time period.
Detailed Explanation
HTTP is stateless—each request is independent with no memory of previous requests. Sessions solve this by storing user state on the server and identifying the user with a session ID (typically stored in a cookie). When a user logs in, a session is created; when they log out or the session expires, it is destroyed.
Sessions can be stored in-memory (simple but doesn't scale), in a database (persistent but adds latency), or in a distributed cache like Redis (scalable and fast). Session management includes handling timeouts, concurrent session limits, and secure session storage. JWTs are often considered an alternative to server-side sessions.
Why It Matters
Sessions are how web applications remember logged-in users and maintain state across requests. Understanding session management is essential for secure, scalable applications.
Real-World Example
When you log into an online store, a session is created that tracks your shopping cart, preferences, and authentication state. You can browse multiple pages without re-entering your password because the session persists your login.
When to Use
When you need to maintain user state across requests in a traditional server-rendered application, or when you need server-side control over session lifecycle.
Advantages
- Server-side control over session lifecycle
- Easy to revoke (just delete the session)
- No sensitive data sent to the client
- Works with any client type
- Simple to implement with frameworks
Disadvantages
- Requires server-side storage
- Doesn't scale easily without distributed session store
- Session fixation and hijacking risks
- Cookie-based session IDs can be stolen
- Cross-origin issues in SPAs
Related Terms
Frequently Asked Questions
What is the difference between session and JWT?
Sessions store state on the server and use a session ID cookie. JWTs store state in the token itself and are validated without server lookups. Sessions are easier to revoke; JWTs scale better.
How long should sessions last?
Depends on sensitivity. Banking apps: 5-15 minutes of inactivity. Regular apps: 30 minutes to 2 hours. Remember-me tokens: 30-90 days. Always set both idle timeout and absolute timeout.
Where are sessions stored?
Common storage: in-memory (simple, single server), files (basic persistence), databases (durable but slower), and distributed caches like Redis (fast, scalable, recommended for production).
How do I prevent session hijacking?
Use HTTPS only, set the Secure flag on session cookies, implement HttpOnly to prevent JavaScript access, use SameSite to prevent CSRF, regenerate session IDs after login, and bind sessions to IP or user agent.
Should I use sessions or JWTs?
Use sessions for traditional server-rendered apps where you need server-side control. Use JWTs for APIs, SPAs, and microservices where stateless authentication and horizontal scaling are priorities.