Session-based and Token-based Authentication Methods
Overview
In web application development, the choice of authentication method is a design decision that significantly impacts the system's scalability, security, and maintainability. This article provides a comprehensive comparison and explanation of session-based and token-based authentication, from technical details to implementation considerations.
Basics of Authentication
What is Authentication?
Authentication is the process of verifying that a user attempting to access a system is indeed who they claim to be. It involves verifying the user's identity to ensure that only legitimate users can access the system.
Difference between Authentication and Authorization:
- Authentication: Verifying "who you are"
- Authorization: Determining "what you can do"
Features
The basic features provided by an authentication system include:
-
Identity Verification
- Matching user ID and password
- Support for multi-factor authentication (MFA)
- Extensibility to biometric and certificate authentication
-
Session Management
- Maintaining login state
- Managing session expiration
- Logout processing
-
Security Control
- Applying password policies
- Account lockout functionality
- Detection and prevention of unauthorized access
-
Audit and Logging
- Recording login and logout activities
- Tracking authentication failures
- Monitoring security events
Non-functional Requirements
Non-functional requirements for an authentication system include:
-
Performance
- Fast authentication processing
- Handling a large number of simultaneous authentication requests
- Stability of response times
-
Scalability
- Linear scaling with the increase in user numbers
- Support for horizontal scaling
- Efficiency of load balancing
-
Availability
- High availability (target: 99.9% or more)
- Automatic recovery in case of failure
- Ensuring service continuity
-
Security
- Encrypted communication (TLS)
- Secure storage of authentication information
- Protection against session hijacking
-
Maintainability
- Ease of configuration changes
- Efficiency of monitoring and operations
- Speed of incident response
As a core function of the system, high availability and scalability are required.
Session-based Authentication
Architecture
Session-based authentication is a method where the server manages the user's login state.
graph TB
subgraph "Client Side"
Browser[Browser]
end
subgraph "Server Side"
LB[Load Balancer]
App1[App Server 1]
App2[App Server 2]
App3[App Server 3]
Session[(Session Store<br/>Redis/Database)]
DB[(User DB)]
end
Browser -->|Cookie: sessionid| LB
LB --> App1
LB --> App2
LB --> App3
App1 <-->|Session Read/Write| Session
App2 <-->|Session Read/Write| Session
App3 <-->|Session Read/Write| Session
App1 <-->|User Info Retrieval| DB
App2 <-->|User Info Retrieval| DB
App3 <-->|User Info Retrieval| DB
The main components include:
- Session Store: Stores session information (Redis, Database, etc.)
- Session ID: A unique identifier issued to the client
- Cookie: Holds the session ID on the client side
Sequence
Login Flow
sequenceDiagram
participant U as User
participant B as Browser
participant S as Server
participant SS as Session Store
participant DB as User DB
U->>B: Enter login information
B->>S: POST /login (ID, Password)
S->>DB: User authentication
DB-->>S: Authentication result
alt Authentication Success
S->>S: Generate session ID
S->>SS: Save session information
SS-->>S: Save complete
S-->>B: Set-Cookie: sessionid=xxx
B-->>U: Login success
else Authentication Failure
S-->>B: 401 Unauthorized
B-->>U: Login failure
end
Authenticated Request Flow
sequenceDiagram
participant B as Browser
participant S as Server
participant SS as Session Store
participant DB as App DB
B->>S: GET /api/data (Cookie: sessionid=xxx)
S->>SS: Check session
SS-->>S: Session information
alt Session Valid
S->>DB: Retrieve data
DB-->>S: Data
S-->>B: 200 OK + Data
else Session Invalid/Expired
S-->>B: 401 Unauthorized
end
Logout Flow
sequenceDiagram
participant B as Browser
participant S as Server
participant SS as Session Store
B->>S: POST /logout (Cookie: sessionid=xxx)
S->>SS: Delete session
SS-->>S: Delete complete
S-->>B: Set-Cookie: sessionid=deleted
B-->>B: Delete Cookie
Advantages and Disadvantages
Advantages
-
Security
- Session information is managed on the server side
- Immediate reflection of session invalidation
- Sensitive information is not stored on the client side
-
Simple Implementation
- Established method with a long history
- Implementable with standard framework features
- Easy debugging and troubleshooting
-
Granular Control
- Flexible session timeout settings
- Dynamic updates of session information possible
- Session management on a per-user basis
-
Browser Compatibility
- Seamless experience with automatic cookie transmission
- Operates even in environments where JavaScript is disabled
- Easy combination with CSRF protection
Disadvantages
-
Scalability Constraints
- Session store can become a single point of failure
- Complexity during horizontal scaling
- Capacity limitations of the session store
-
Performance Issues
- Requires session store access for every request
- Impact of network latency
- Load concentration on the session store
-
Operational Complexity
- Requires monitoring and maintenance of the session store
- Session synchronization in distributed environments
- Considerations for backup and recovery
-
Multi-platform Support
- Constraints on cookie management in mobile apps
- Complexity in API integration
- Difficulty in sharing authentication information among microservices
-
Impact During Failures
- Session store failure affects all users
- Complexity of session migration during scale-out
- Challenges in session recovery during disaster recovery
Token-based Authentication
Architecture
Token-based authentication is a method where the client holds a token and sends it with each request for authentication.
graph TB
subgraph "Client Side"
Browser[Browser]
Token[JWT Token<br/>Local Storage]
end
subgraph "Server Side"
LB[Load Balancer]
App1[App Server 1]
App2[App Server 2]
App3[App Server 3]
Auth[Auth Server]
DB[(User DB)]
end
Browser <-->|Token Save/Retrieve| Token
Browser -->|Authorization: Bearer token| LB
LB --> App1
LB --> App2
LB --> App3
App1 -->|Token Verification| App1
App2 -->|Token Verification| App2
App3 -->|Token Verification| App3
Browser -.->|Only during initial authentication| Auth
Auth -.->|Issue JWT| Browser
Auth <-->|User Info Retrieval| DB
The main components include:
- JWT Token: A self-contained token containing user information and permissions
- Auth Server: Responsible for issuing and managing tokens
- Local Storage: Stores tokens on the client side
Sequence
Login Flow
sequenceDiagram
participant U as User
participant B as Browser
participant Auth as Auth Server
participant DB as User DB
U->>B: Enter login information
B->>Auth: POST /auth/login (ID, Password)
Auth->>DB: User authentication
DB-->>Auth: Authentication result
alt Authentication Success
Auth->>Auth: Generate JWT Token
Auth-->>B: 200 OK + JWT Token
B->>B: Save token to local storage
B-->>U: Login success
else Authentication Failure
Auth-->>B: 401 Unauthorized
B-->>U: Login failure
end
Authenticated Request Flow
sequenceDiagram
participant B as Browser
participant S as Server
participant DB as App DB
B->>B: Retrieve token from local storage
B->>S: GET /api/data (Authorization: Bearer token)
S->>S: Token verification (signature, expiration, issuer)
alt Token Valid
S->>DB: Retrieve data
DB-->>S: Data
S-->>B: 200 OK + Data
else Token Invalid/Expired
S-->>B: 401 Unauthorized
end
Logout Flow
sequenceDiagram
participant B as Browser
participant Auth as Auth Server
B->>B: Delete token from local storage
B->>Auth: POST /auth/logout
Auth->>Auth: Record logout (for audit)
Auth-->>B: 200 OK
Note: Since JWT tokens are self-contained, immediate invalidation on the server side is difficult. Actual invalidation is achieved through the following methods:
- Client-side Deletion: Delete the token from local storage (primary invalidation method)
- Short Expiration: Set a short expiration time for access tokens (15 minutes to 1 hour)
- Refresh Token Invalidation: Invalidate only the refresh token on the server side
- Key Rotation: Change the signing key in emergencies to invalidate all tokens
Advantages and Disadvantages
Advantages
-
Scalability
- No need for session management on the server side
- Easy horizontal scaling
- Each app server can independently verify tokens
-
Performance
- No need for session store access
- Fast authentication processing with local verification
- Reduced network communication
-
Multi-platform Support
- Easy implementation in mobile apps
- Standard method for API integration
- Easy sharing of authentication information among microservices
-
Statelessness
- No need to maintain state on the server side
- Simple load balancing
- Limited impact during failures
-
Standardization
- Compliance with industry standards like JWT
- Abundance of libraries and tools
- Easy integration with other systems
Disadvantages
-
Security Risks
- Tokens are stored on the client side (threat of XSS attacks)
- Large impact if tokens are stolen
- Difficult immediate invalidation on the server side (due to JWT's self-contained nature)
- Security risks when using local storage
-
Token Size
- JWT is larger than a typical session ID
- Further bloating if it includes permission information
- Impact on network bandwidth
-
Complexity of Implementation
- Management of access and refresh token pairs
- Many security considerations (key management, signature algorithms)
- Implementation of token refresh flow
- Consideration of key rotation strategy
-
Difficulty in Debugging
- Need to check token contents
- Complexity in identifying issues in distributed environments
- Complexity of log management
-
Browser Limitations
- Size limitations of local storage
- Vulnerability to XSS attacks
- Constraints in private browsing
Comparison by Method
Technical Feature Comparison
| Item | Session-based | Token-based |
|---|---|---|
| State Management | Stateful (server-side state) | Stateless (information in token) |
| Data Storage | Server-side (session store) | Client-side (local storage, etc.) |
| Network Communication | Session check for every request | Token verification only (local processing) |
| Scalability | Dependent on session store | Easy horizontal scaling |
| Security Model | Server-side control | Distributed client-server model |
Performance Comparison
| Metric | Session-based | Token-based |
|---|---|---|
| Authentication Time | Dependent on session store access time | Token verification time (usually a few ms) |
| Network Load | Session ID (small) | JWT (medium to large) |
| Server Load | Read/write to session store | CPU-intensive signature verification |
| Memory Usage | Proportional to number of sessions | Almost constant |
Security Comparison
| Threat | Session-based | Token-based |
|---|---|---|
| Session Fixation Attack | Vulnerable (requires countermeasures) | No impact |
| Session Hijacking | Vulnerable (HTTPS required) | Vulnerable (HTTPS required) |
| XSS Attack | Mitigated with HttpOnly Cookie | Vulnerable when using local storage |
| CSRF Attack | Vulnerable (CSRF Token required) | Minimal impact |
| Token Leakage | Limited impact if session ID is leaked | Large impact if JWT is leaked |
Selection Guidelines
When Session-based Authentication is Suitable
-
Traditional Web Applications
- Server-side rendering focused
- Operated within a single domain
- Emphasis on compatibility with existing systems
-
High Security Requirements
- Immediate session invalidation needed
- Desire for complete server-side control
- Financial systems, etc.
-
Desire for Simple Architecture
- Small to medium-sized applications
- Skill level of the operations team
- Minimization of development and maintenance costs
When Token-based Authentication is Suitable
-
Modern Web Applications
- SPA (Single Page Application)
- Microservices architecture
- API-centric design
-
Scalability is Important
- Large user base
- Need for horizontal scaling
- Cloud-native environment
-
Multi-platform Support
- Integration with mobile apps
- Use across multiple domains
- Integration with external APIs
Considerations for Implementation
Key Points for Implementing Session-based Authentication
-
Choice of Session Store
- Redis: High performance, distributed support
- Database: Persistence, transaction support
- Memory: Simple, limited to single server
-
Security Measures
- Setting HttpOnly, Secure Cookie
- Implementation of CSRF Token
- Countermeasures against session fixation attacks
-
Operational Considerations
- Monitoring of session store
- Backup and recovery procedures
- Sticky Session settings during load balancing
Key Points for Implementing Token-based Authentication
-
Token Design
- Access Token
- Refresh Token
- Minimal payload
- Safe update mechanism with token pairs
-
Security Measures
- Strong signature algorithm (RS256 recommended)
- Key management and rotation strategy
- Choice of token storage location
-
Operational Considerations
- Mechanism for token invalidation
- Infrastructure for key management
- Design of audit logs
Conclusion
Session-based and token-based authentication are authentication methods with different characteristics and applicable scenarios.
Choosing the appropriate authentication method requires comprehensive consideration of system requirements, scale, security demands, development team skills, and operational setup. A hybrid approach combining both methods is also possible.
As technology advances, authentication methods continue to evolve, making it important to keep abreast of technological trends and periodically review authentication methods to align with system growth.
