JWT vs session-based decision in Spring Boot - Hands-On Comparison

JWT vs Session-Based Authentication Decision in Spring Boot

📖 Scenario: You are building a Spring Boot web application that needs user authentication. You want to decide whether to use JWT (JSON Web Tokens) or session-based authentication based on the app's needs.This project will guide you through setting up data and logic to choose the best authentication method.

🎯 Goal: Build a simple Spring Boot configuration that holds user data, a setting for authentication type, and logic to decide between JWT and session-based authentication.

📋 What You'll Learn

Create a user data map with exact usernames and roles

Add a configuration variable to select authentication type

Write logic to check the authentication type and print the chosen method

Complete the Spring Boot component with the final annotation

💡 Why This Matters

🌍 Real World

Choosing the right authentication method is important for web apps to balance security, scalability, and user experience.

💼 Career

Understanding how to configure and decide between JWT and session-based authentication is a key skill for backend developers working with Spring Boot.

1

Create user data map

Create a Map<String, String> called users with these exact entries: "alice" : "USER", "bob" : "ADMIN", and "carol" : "USER".

Spring Boot

// Your code here

Hint

Use Map.of() to create a small map with usernames as keys and roles as values.

2

Add authentication type configuration

Add a String variable called authType and set it to the exact value "JWT".

Spring Boot

Map users = Map.of(
    "alice", "USER",
    "bob", "ADMIN",
    "carol", "USER"
);
// Your code here

Hint

Just create a string variable named authType and assign it the value "JWT".

3

Write decision logic for authentication

Write an if statement that checks if authType equals "JWT". Inside the if, assign "Using JWT authentication" to a String variable called decision. Otherwise, assign "Using session-based authentication" to decision.

Spring Boot

Map users = Map.of(
    "alice", "USER",
    "bob", "ADMIN",
    "carol", "USER"
);

String authType = "JWT";
// Your code here

Hint

Use authType.equals("JWT") to compare strings in Java.

4

Complete Spring Boot component

Add the @Component annotation above the class declaration to make this a Spring Boot component.

Spring Boot

@Component
import java.util.Map;

public class AuthDecision {

    Map users = Map.of(
        "alice", "USER",
        "bob", "ADMIN",
        "carol", "USER"
    );

    String authType = "JWT";

    String decision;

    public void decide() {
        if (authType.equals("JWT")) {
            decision = "Using JWT authentication";
        } else {
            decision = "Using session-based authentication";
        }
    }
}
// Your code here

Hint

Use @Component annotation from Spring Framework to mark the class as a component.

Practice

1. Which statement best describes JWT authentication in Spring Boot?

easy

A. User info is stored on the server and tracked with cookies.

B. User info is stored only in the database without tokens or sessions.

C. User info is stored in a token sent with each request, no server storage needed.

D. User info is stored in browser local storage only.

Solution

1. Step 1: Understand JWT storage method

   JWT stores user information inside a token that is sent with every request, so the server does not need to keep session data.

2. Step 2: Compare with session storage

   Sessions store user info on the server and use cookies to track users, unlike JWT which is stateless.

3. Final Answer:

   User info is stored in a token sent with each request, no server storage needed. -> Option C

4. Quick Check:

   JWT = token-based stateless auth [OK]

Hint: JWT stores info in tokens, sessions store on server [OK]

Common Mistakes:

• Confusing JWT with session storage
• Thinking JWT requires server-side storage
• Believing JWT info is only in browser storage

2. Which code snippet correctly sets a session attribute in Spring Boot?

easy

A. request.getSession().setAttribute("user", userObject);

B. request.setSessionAttribute("user", userObject);

C. session.setAttribute("user", userObject);

D. request.session().setAttribute("user", userObject);

Solution

1. Step 1: Recall correct method to get session

   In Spring Boot, you get the session from the request using request.getSession().

2. Step 2: Set attribute on session object

   Then call setAttribute("user", userObject) on the session to store data.

3. Final Answer:

   request.getSession().setAttribute("user", userObject); -> Option A

4. Quick Check:

   Use getSession() then setAttribute() [OK]

Hint: Use request.getSession() before setAttribute [OK]

Common Mistakes:

• Calling setAttribute directly on request
• Using incorrect method names like setSessionAttribute
• Trying to call session() as a method on request

3. Given this Spring Boot code snippet using JWT, what is the expected behavior?

String token = jwtUtil.generateToken(userDetails);
response.setHeader("Authorization", "Bearer " + token);
// No session is created on server

medium

A. User info is stored on server session and token is ignored.

B. Token is sent to client; server remains stateless without session.

C. Session is created on server with token stored inside.

D. Token is stored in server memory for each user.

Solution

1. Step 1: Analyze token generation and response header

   The code generates a JWT token and sends it in the Authorization header to the client.

2. Step 2: Note server session behavior

   The comment says no session is created on the server, meaning the server stays stateless.

3. Final Answer:

   Token is sent to client; server remains stateless without session. -> Option B

4. Quick Check:

   JWT = stateless token sent to client [OK]

Hint: JWT sends token, no server session created [OK]

Common Mistakes:

• Assuming server stores token in session
• Thinking token is ignored by server
• Believing token is stored in server memory

4. Identify the error in this Spring Boot session code snippet:

HttpSession session = request.getSession(false);
session.setAttribute("user", userObject);

medium

A. Session attributes cannot store user objects.

B. setAttribute method does not exist on HttpSession.

C. request.getSession(false) always creates a new session.

D. Using getSession(false) may return null causing NullPointerException.

Solution

1. Step 1: Understand getSession(false) behavior

   getSession(false) returns existing session or null if none exists; it does not create a new session.

2. Step 2: Check for possible null usage

   If session is null, calling setAttribute causes NullPointerException.

3. Final Answer:

   Using getSession(false) may return null causing NullPointerException. -> Option D

4. Quick Check:

   getSession(false) can return null [OK]

Hint: getSession(false) may return null, check before use [OK]

Common Mistakes:

• Assuming getSession(false) always returns a session
• Believing setAttribute is invalid method
• Thinking sessions cannot store objects

5. You are building a Spring Boot app that must scale across many servers without sticky sessions. Which authentication method should you choose and why?

hard

A. Use JWT because it is stateless and does not require server session storage.

B. Use JWT but store tokens in server memory for faster access.

C. Use session-based authentication with distributed cache to share sessions.

D. Use session-based authentication because it stores user info on the server.

Solution

1. Step 1: Understand scaling needs

   Scaling across many servers without sticky sessions means no single server holds user session data.

2. Step 2: Compare authentication methods

   Session-based auth stores user info on server, requiring session sharing or sticky sessions, which complicates scaling.

3. Step 3: Choose JWT for statelessness

   JWT stores user info in tokens sent with requests, so servers remain stateless and scaling is easier.

4. Final Answer:

   Use JWT because it is stateless and does not require server session storage. -> Option A

5. Quick Check:

   Stateless JWT best for scalable multi-server apps [OK]

Hint: Stateless JWT fits multi-server scaling best [OK]

Common Mistakes:

• Choosing sessions without sticky sessions or shared cache
• Thinking JWT requires server memory storage
• Ignoring stateless benefits of JWT