Stateless authentication mental model in Spring Boot - Step-by-Step Execution

Concept Flow - Stateless authentication mental model

Client sends login request

↓

Server verifies credentials

↓

Server creates token (e.g., JWT)

↓

Server sends token to client

↓

Client stores token locally

↓

Client sends token with each request

↓

Server validates token without session

↓

Server processes request if token valid

↓

Repeat for each request without server session

The server issues a token after login, and the client sends it with each request. The server checks the token each time without storing session data.

Execution Sample

Spring Boot

POST /login {username, password}
Server: verify credentials
Server: create JWT token
Response: send token
Client: store token
Client: send token in Authorization header
Server: validate token
Server: respond to request

This flow shows how stateless authentication uses tokens to verify users without server sessions.

Execution Table

Step	Action	Input	Server State	Output/Result
1	Client sends login request	{username, password}	No session	Login request received
2	Server verifies credentials	{username, password}	No session	Credentials valid
3	Server creates token	User info	No session	JWT token created
4	Server sends token to client	JWT token	No session	Token sent in response
5	Client stores token	JWT token	No session	Token saved locally
6	Client sends token with request	JWT token in header	No session	Request with token received
7	Server validates token	JWT token	No session	Token valid
8	Server processes request	Valid token	No session	Requested data sent
9	Client sends next request with token	JWT token	No session	Repeat validation and processing
10	Session not stored on server	N/A	No session	Stateless authentication continues

💡 Server never stores session; each request must include a valid token to be processed.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
credentials	None	{username, password}	{username, password}	{username, password}	None
token	None	JWT token created	JWT token stored on client	JWT token validated	JWT token validated
server_session	None	None	None	None	None

Key Moments - 3 Insights

Why doesn't the server store any session data?

Because the server uses the token sent with each request to verify identity, it does not need to keep session data. See execution_table rows 7 and 10.

What happens if the client forgets to send the token?

The server cannot validate the user without the token, so it will reject the request. This is shown in execution_table row 6 where the token must be included.

How does the server know the user is authenticated on each request?

The server validates the token included in the request headers each time, as shown in execution_table row 7.

Visual Quiz - 3 Questions

Look at the execution_table, what is the server state after step 3?

A Session created for user

B No session stored

C Token stored on server

D User logged out

💡 Hint

Check the 'Server State' column at step 3 in the execution_table.

At which step does the client store the token locally?

A Step 5

B Step 4

C Step 2

D Step 7

💡 Hint

Look for the action 'Client stores token' in the execution_table.

If the client sends a request without a token, what will happen according to the model?

A Server processes request normally

B Server creates a new token

C Server rejects the request

D Server stores a session for the client

💡 Hint

Refer to the key moment about missing token and execution_table step 6.

Concept Snapshot

Stateless authentication means the server does not keep session data.
After login, server sends a token (like JWT) to client.
Client stores token and sends it with every request.
Server validates token each time to authenticate.
No server session means easier scaling and simpler server logic.

Full Transcript

Stateless authentication in Spring Boot works by the server issuing a token after verifying user credentials during login. This token, often a JWT, contains user information and is sent back to the client. The client stores this token locally, for example in local storage or a cookie. For every subsequent request, the client includes this token in the Authorization header. The server then validates the token on each request without storing any session data. If the token is valid, the server processes the request; otherwise, it rejects it. This approach means the server remains stateless, simplifying scaling and reducing server memory use. The execution table shows each step from login to repeated requests, highlighting that the server never creates or stores a session. Key moments clarify common confusions like why no session is stored and what happens if the token is missing. The visual quiz tests understanding of token storage, server state, and request validation.

Practice

1. What is the main idea behind stateless authentication in Spring Boot?

easy

A. The server does not keep user session data; clients send tokens each time.

B. The server stores all user sessions in memory for quick access.

C. The server uses cookies to remember users between requests.

D. The server requires users to log in for every single request manually.

Solution

1. Step 1: Understand stateless authentication concept

   Stateless means the server does not save any user session data between requests.

2. Step 2: Identify how user identity is maintained

   Clients send a token with each request to prove who they are without server memory.

3. Final Answer:

   The server does not keep user session data; clients send tokens each time. -> Option A

4. Quick Check:

   Stateless = No server session, token sent each time [OK]

Hint: Stateless means no server memory, token sent every request [OK]

Common Mistakes:

• Thinking server stores session data
• Confusing cookies with stateless tokens
• Assuming login required every request

2. Which of the following is the correct way to send a token in a stateless Spring Boot API request?

easy

A. Include the token in the request body as plain text.

B. Send the token in the Authorization header as a Bearer token.

C. Store the token in a server-side session variable.

D. Attach the token as a URL query parameter without encoding.

Solution

1. Step 1: Recall token transmission best practice

   Tokens are usually sent in the Authorization header using the Bearer scheme.

2. Step 2: Eliminate incorrect methods

   Request body is not standard for tokens; server-side session breaks statelessness; URL query parameters are insecure and not recommended.

3. Final Answer:

   Send the token in the Authorization header as a Bearer token. -> Option B

4. Quick Check:

   Token in Authorization header = correct [OK]

Hint: Tokens go in Authorization header as Bearer [OK]

Common Mistakes:

• Putting token in request body
• Using server session storage
• Sending token in URL query insecurely

3. Given this Spring Boot controller snippet using stateless authentication:

@GetMapping("/profile")
public ResponseEntity<String> getProfile(@RequestHeader("Authorization") String authHeader) {
    if (authHeader == null || !authHeader.startsWith("Bearer ")) {
        return ResponseEntity.status(401).body("Unauthorized");
    }
    String token = authHeader.substring(7);
    if (token.equals("valid-token")) {
        return ResponseEntity.ok("User Profile Data");
    } else {
        return ResponseEntity.status(403).body("Forbidden");
    }
}

What will be the response if the client sends header Authorization: Bearer valid-token?

medium

A. 401 Unauthorized

B. 403 Forbidden

C. 200 OK with 'User Profile Data'

D. 500 Internal Server Error

Solution

1. Step 1: Check Authorization header presence and format

   The header is present and starts with "Bearer ", so it passes the first check.

2. Step 2: Extract token and compare

   The token extracted is "valid-token", which matches the expected valid token.

3. Step 3: Determine response

   Since token is valid, the method returns 200 OK with "User Profile Data".

4. Final Answer:

   200 OK with 'User Profile Data' -> Option C

5. Quick Check:

   Valid token = 200 OK response [OK]

Hint: Valid Bearer token returns 200 OK [OK]

Common Mistakes:

• Confusing 401 and 403 status codes
• Ignoring token prefix check
• Assuming server stores session

4. Identify the bug in this stateless authentication filter code snippet:

public boolean isValidToken(String token) {
    if (token == null || token.isEmpty()) {
        return false;
    }
    // Token validation logic
    return token.equals("valid-token");
}

public void doFilter(HttpServletRequest req, HttpServletResponse res) {
    String auth = req.getHeader("Authorization");
    if (auth != null && auth.startsWith("Bearer ")) {
        String token = auth.substring(7);
        if (!isValidToken(token)) {
            res.setStatus(401);
        }
    }
    // Continue filter chain
}

What is the main issue?

medium

A. Possible NullPointerException if Authorization header is missing

B. Token validation logic is incorrect

C. Response status code should be 403 instead of 401

D. Filter does not extract token correctly

Solution

1. Step 1: Analyze header usage

   The original code calls auth.startsWith("Bearer ") without checking if auth is null.

2. Step 2: Identify risk

   If Authorization header is missing, auth is null, so calling startsWith causes NullPointerException.

3. Final Answer:

   Possible NullPointerException if Authorization header is missing -> Option A

4. Quick Check:

   Check null before startsWith to avoid error [OK]

Hint: Check for null before calling startsWith [OK]

Common Mistakes:

• Assuming header always present
• Mixing 401 and 403 status codes
• Ignoring null safety in Java

5. In a stateless Spring Boot app using JWT tokens, which approach best supports scaling across multiple servers?

hard

A. Store user sessions in a shared database accessed by all servers.

B. Cache user sessions in server memory for faster access.

C. Use sticky sessions to keep users on the same server.

D. Validate JWT tokens on each request without server session storage.

Solution

1. Step 1: Understand stateless scaling needs

   Scaling means any server can handle any request without shared session state.

2. Step 2: Evaluate options

   Storing sessions in DB or memory adds state and complexity; sticky sessions tie users to one server, limiting scaling.

3. Step 3: Identify best stateless method

   Validating JWT tokens on each request keeps servers stateless and allows easy scaling.

4. Final Answer:

   Validate JWT tokens on each request without server session storage. -> Option D

5. Quick Check:

   Stateless + JWT = validate token each request [OK]

Hint: Stateless scaling means no server session, validate tokens each time [OK]

Common Mistakes:

• Using sticky sessions limits scaling
• Storing sessions breaks statelessness
• Caching sessions in memory causes sync issues