Session-Based Authentication vs. JWT: Understanding Key Differences and Implementation

When building secure web applications, choosing the right authentication mechanism is crucial. Two popular methods are Session-based authentication and JSON Web Tokens (JWT). Each has its own approach to managing user authentication and session management, with distinct advantages and drawbacks. Session-based authentication, a traditional method, relies on server-side storage of session information, providing a straightforward and secure way to manage users. On the other hand, JWTs are a modern, stateless alternative, allowing scalability and flexibility, especially in distributed systems and microservices. In this post, we'll explore the key differences between these two methods and provide insights into their implementations, helping you make an informed decision for your application's security architecture.

Session-based Authentication:

- How it works:

- When a user logs in, the server creates a session and stores it in the server's memory or a database.

- The server sends a session ID (usually stored in a cookie) to the client, and the client includes this session ID with each subsequent request.

- The server checks its session store to verify the session ID and authenticates the user.

- Where data is stored:

- The actual session data (user information, etc.) is stored on the server.

- The client only stores a reference (session ID) to this session.

- Pros:

- Easy to implement and secure (as long as HTTPS is used).

- Server controls sessions, so revoking access is straightforward (just remove the session).

- Cons:

- Scalability issues: The server needs to store sessions, which can be a burden as the number of users increases.

- Load balancing can be complicated because sessions need to be consistent across multiple servers.

JWT-based Authentication:

- How it works:

- When a user logs in, the server generates a JWT (a self-contained token) that contains user information and possibly permissions/roles, signed with a secret key.

- The token is sent to the client, which stores it (usually in local storage or cookies) and includes it with each request.

- The server validates the JWT signature to authenticate the user; it does not need to store any session information.

- Where data is stored:

- The token, containing all the relevant information, is stored on the client side.

- The server does not need to keep track of individual sessions.

- Pros:

- Scalability: The server doesn’t need to maintain a session store, making it easier to scale horizontally.

- Stateless: Suitable for distributed systems and microservices.

- Flexibility: JWTs can carry additional information (e.g., user roles), allowing for more decentralized access control.

- Cons:

- Security risks if the token is not handled properly (e.g., if stored in local storage and exposed to XSS attacks).

- Token revocation is challenging; once a JWT is issued, it remains valid until it expires unless additional mechanisms like a blacklist are used.

- Larger token size compared to a simple session ID.

Session-based Authentication in Spring Boot

Explanation:

• The server creates and manages sessions for each user. The session ID is stored on the client as a cookie (JSESSIONID), which is sent with every request.
• The server checks the session store (managed by Spring Security) to validate and authenticate the request.

Complete Implementation:

1. Dependencies: Add the following dependency in pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>        

2. Security Configuration:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf().disable()
            .authorizeRequests()
                .antMatchers("/login", "/register").permitAll() // Public endpoints
                .anyRequest().authenticated() // All other endpoints need authentication
            .and()
            .formLogin()
                .loginPage("/login")
                .defaultSuccessUrl("/home", true) // Redirect after successful login
            .and()
            .logout()
                .logoutUrl("/logout")
                .logoutSuccessUrl("/login?logout");
    }
}        

3. Login and Logout Handling:

@RestController
public class AuthController {

    @PostMapping("/login")
    public String login() {
        return "User logged in successfully!";
    }

    @GetMapping("/home")
    public String home() {
        return "Welcome to the protected home page!";
    }

    @PostMapping("/logout")
    public String logout() {
        return "User logged out successfully!";
    }
}        

How It Works:

• /login and /logout endpoints are managed by Spring Security.
• The user logs in, and Spring Security sets a JSESSIONID cookie.
• This cookie is automatically sent with subsequent requests, and the session is validated.

JWT-based Authentication in Spring Boot

Explanation:

• The server issues a JWT upon user login, which the client stores and includes in each request’s Authorization header.
• The server validates the token and retrieves user information from it without needing to maintain a session store.

Complete Implementation:

Dependencies: Include the following dependencies in pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>        

JWT Utility Class:

@Component
public class JwtUtil {
    private String SECRET_KEY = "your_secret_key";

    public String generateToken(UserDetails userDetails) {
        Map<String, Object> claims = new HashMap<>();
        return createToken(claims, userDetails.getUsername());
    }

    private String createToken(Map<String, Object> claims, String subject) {
        return Jwts.builder().setClaims(claims).setSubject(subject)
                .setIssuedAt(new Date(System.currentTimeMillis()))
                .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 10)) // Token valid for 10 hours
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY).compact();
    }

    public String extractUsername(String token) {
        return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody().getSubject();
    }

    public boolean validateToken(String token, UserDetails userDetails) {
        final String username = extractUsername(token);
        return (username.equals(userDetails.getUsername()) && !isTokenExpired(token));
    }

    private boolean isTokenExpired(String token) {
        return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody().getExpiration().before(new Date());
    }
}        

JWT Authentication Filter:

public class JwtRequestFilter extends OncePerRequestFilter {

    @Autowired
    private JwtUtil jwtUtil;

    @Autowired
    private UserDetailsService userDetailsService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {
        final String authorizationHeader = request.getHeader("Authorization");

        String username = null;
        String jwt = null;

        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            jwt = authorizationHeader.substring(7);
            username = jwtUtil.extractUsername(jwt);
        }

        if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
            UserDetails userDetails = this.userDetailsService.loadUserByUsername(username);
            if (jwtUtil.validateToken(jwt, userDetails)) {
                UsernamePasswordAuthenticationToken authenticationToken = 
                     new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
                authenticationToken.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                SecurityContextHolder.getContext().setAuthentication(authenticationToken);
            }
        }
        chain.doFilter(request, response);
    }
}        

Security Configuration:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private JwtRequestFilter jwtRequestFilter;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .authorizeRequests()
                .antMatchers("/authenticate").permitAll()
                .anyRequest().authenticated()
            .and()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS); // Set session management to stateless

        http.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);
    }
}        

Controller for Authentication:

@RestController
public class JwtAuthenticationController {

    @Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private JwtUtil jwtUtil;

    @Autowired
    private UserDetailsService userDetailsService;

    @PostMapping("/authenticate")
    public ResponseEntity<?> createAuthenticationToken(@RequestBody AuthenticationRequest authenticationRequest) throws Exception {
        authenticationManager.authenticate(
            new UsernamePasswordAuthenticationToken(authenticationRequest.getUsername(), authenticationRequest.getPassword())
        );

        final UserDetails userDetails = userDetailsService.loadUserByUsername(authenticationRequest.getUsername());
        final String jwt = jwtUtil.generateToken(userDetails);

        return ResponseEntity.ok(new AuthenticationResponse(jwt));
    }
}        

• The user logs in at /authenticate with credentials, and if successful, a JWT is returned.
• The JWT is stored on the client and sent in the Authorization header for subsequent requests.
• The JwtRequestFilter validates the token, and if valid, sets the user in the security context.

Summary:

- Session-based: Server-side, stateful, easier to manage revocation, less scalable.

- JWT-based: Client-side, stateless, scalable, but requires more careful security measures and handling for revocation.