Why JWT matters for APIs in Spring Boot - Visual Breakdown

Concept Flow - Why JWT matters for APIs

Client sends login request

↓

Server verifies credentials

↓

Server creates JWT token

↓

Server sends JWT to client

↓

Client stores JWT

↓

Client sends API requests with JWT

↓

Server verifies JWT

↓

Valid

↓

Allow access

↓

Respond accordingly

This flow shows how JWT is created after login, sent to client, then used to authorize API requests by verifying the token on each request.

Execution Sample

Spring Boot

POST /login -> verify user -> create JWT -> send JWT
Client stores JWT
Client sends API request with JWT
Server verifies JWT -> allow or reject

This code flow shows the key steps of JWT usage in API authentication and authorization.

Execution Table

Step	Action	Input	Output	Result
1	Client sends login request	username/password	Request received	Server ready to verify
2	Server verifies credentials	username/password	Valid user	Proceed to create JWT
3	Server creates JWT token	User info	JWT token string	Token ready to send
4	Server sends JWT to client	JWT token	HTTP response with token	Client receives token
5	Client stores JWT	JWT token	Stored in memory/local storage	Ready for API calls
6	Client sends API request with JWT	API request + JWT	Request received with token	Server verifies token
7	Server verifies JWT	JWT token	Valid or invalid	Decision to allow or reject
8	If valid	Valid token	Process API request	Respond with data
9	If invalid	Invalid token	Reject request	Respond with error
10	End	N/A	N/A	Request cycle complete

💡 Execution stops after server responds to API request based on JWT validity.

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
username/password	User input	Verified	N/A	N/A	N/A
JWT token	None	Created	Stored on client	Verified	Used or rejected
API request	None	None	Sent with JWT	Processed or rejected	Response sent

Key Moments - 3 Insights

Why does the server create a JWT token after verifying credentials?

Because the JWT token acts like a digital badge proving the user is authenticated, so the client can use it for future API requests without logging in again. See execution_table step 3.

What happens if the JWT token is invalid when the client sends an API request?

The server rejects the request and sends an error response, preventing unauthorized access. See execution_table steps 7 and 9.

Why does the client store the JWT token after receiving it?

So it can include the token in the header of future API requests to prove identity without sending username/password again. See execution_table step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after the server verifies credentials at step 2?

A Valid user

B JWT token string

C Request rejected

D Client stores token

💡 Hint

Check the 'Output' column for step 2 in the execution_table.

At which step does the client send the API request with the JWT token?

A Step 4

B Step 6

C Step 5

D Step 7

💡 Hint

Look for the step where the action is 'Client sends API request with JWT' in the execution_table.

If the JWT token is invalid, what is the server's response according to the execution_table?

A Create new JWT

B Process API request

C Reject request

D Send login request

💡 Hint

See the 'Result' column for step 9 in the execution_table.

Concept Snapshot

JWT (JSON Web Token) is a secure token created after login.
It proves user identity for API requests without resending passwords.
Client stores JWT and sends it with each API call.
Server verifies JWT to allow or reject access.
This keeps APIs secure and stateless.

Full Transcript

This visual execution shows how JWT works for APIs in Spring Boot. First, the client sends login credentials. The server checks them and creates a JWT token if valid. The token is sent back to the client, who stores it. For each API request, the client sends the JWT token. The server verifies the token. If valid, the server processes the request. If invalid, the server rejects it. This flow secures APIs by confirming user identity without repeated logins.

Practice

1. Why is JWT important for APIs in Spring Boot?

easy

A. It replaces the need for HTTPS in API communication.

B. It stores user passwords in the token for quick access.

C. It securely identifies users without storing session data on the server.

D. It automatically encrypts all API responses.

Solution

1. Step 1: Understand JWT's role in user identification

   JWT carries user identity information inside the token, so the server does not need to keep session data.

2. Step 2: Recognize security benefits

   This stateless approach improves security and scalability by avoiding server-side session storage.

3. Final Answer:

   It securely identifies users without storing session data on the server. -> Option C

4. Quick Check:

   JWT = stateless secure user ID [OK]

Hint: JWT carries user info, no server session needed [OK]

Common Mistakes:

• Thinking JWT stores passwords inside the token
• Believing JWT replaces HTTPS
• Assuming JWT encrypts API responses automatically

2. Which of the following is the correct way to include a JWT in an HTTP request header?

easy

A. Auth-Token: <token>

B. Authorization: Bearer <token>

C. Token: JWT <token>

D. JWT-Authorization: Bearer <token>

Solution

1. Step 1: Recall standard JWT header format

   The standard way to send JWTs is in the Authorization header with the Bearer scheme.

2. Step 2: Match the correct syntax

   "Authorization: Bearer <token>" is the correct and widely accepted format.

3. Final Answer:

   Authorization: Bearer <token> -> Option B

4. Quick Check:

   JWT header = Authorization: Bearer [OK]

Hint: JWT goes in Authorization header with Bearer prefix [OK]

Common Mistakes:

• Using non-standard header names like Token or Auth-Token
• Omitting the Bearer prefix
• Adding extra words like JWT-Authorization

3. Given this Spring Boot controller method snippet, what will happen if the JWT is missing or invalid?

@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);
    // Assume validateToken returns false if token invalid
    if (!jwtService.validateToken(token)) {
        return ResponseEntity.status(401).body("Unauthorized");
    }
    return ResponseEntity.ok("User profile data");
}

medium

A. Returns 500 Internal Server Error on invalid JWT.

B. Returns 200 OK with user profile regardless of JWT.

C. Throws a NullPointerException if JWT is missing.

D. Returns 401 Unauthorized if JWT is missing or invalid.

Solution

1. Step 1: Check handling of missing or malformed Authorization header

   The code returns 401 Unauthorized if the header is missing or does not start with "Bearer ".

2. Step 2: Check token validation logic

   If the token is invalid, the method also returns 401 Unauthorized.

3. Final Answer:

   Returns 401 Unauthorized if JWT is missing or invalid. -> Option D

4. Quick Check:

   Missing/invalid JWT = 401 Unauthorized [OK]

Hint: Missing or bad JWT triggers 401 Unauthorized [OK]

Common Mistakes:

• Assuming it returns 200 OK without JWT
• Expecting exceptions instead of 401 response
• Thinking it returns 500 error on invalid token

4. Identify the bug in this Spring Boot JWT filter snippet:

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
    HttpServletRequest req = (HttpServletRequest) request;
    String authHeader = req.getHeader("Authorization");
    if (authHeader != null && authHeader.startsWith("Bearer ")) {
        String token = authHeader.substring(7);
        if (jwtService.validateToken(token)) {
            SecurityContextHolder.getContext().setAuthentication(null);
        }
    }
    chain.doFilter(request, response);
}

medium

A. It sets authentication to null instead of a valid Authentication object.

B. It does not check if authHeader is null before substring.

C. It calls chain.doFilter before validating the token.

D. It uses the wrong header name for JWT.

Solution

1. Step 1: Analyze authentication setting logic

   The code sets authentication to null even when the token is valid, which means no user is authenticated.

2. Step 2: Understand correct behavior

   It should set a valid Authentication object to represent the logged-in user, not null.

3. Final Answer:

   It sets authentication to null instead of a valid Authentication object. -> Option A

4. Quick Check:

   Valid token must set Authentication, not null [OK]

Hint: Valid token must set Authentication object, not null [OK]

Common Mistakes:

• Ignoring that authentication is set to null
• Thinking substring without null check causes error here
• Assuming chain.doFilter order is wrong
• Believing header name is incorrect

5. You want your Spring Boot API to allow users to stay logged in without server sessions, using JWT. Which approach best achieves this while keeping the API stateless and secure?

hard

A. Generate a JWT after login containing user info, send it to client, and require it in Authorization header for each request.

B. Store user sessions in a database and send session IDs in cookies to clients.

C. Send user credentials with every API request and validate each time on the server.

D. Use JWT only for login, then switch to server sessions for other requests.

Solution

1. Step 1: Understand stateless authentication with JWT

   JWT tokens carry user info and are sent by clients with each request, so the server does not store session data.

2. Step 2: Compare with other methods

   Storing sessions or sending credentials every time breaks statelessness or security best practices.

3. Final Answer:

   Generate a JWT after login containing user info, send it to client, and require it in Authorization header for each request. -> Option A

4. Quick Check:

   JWT = stateless secure token per request [OK]

Hint: JWT tokens keep API stateless and secure per request [OK]

Common Mistakes:

• Using server sessions instead of JWT for statelessness
• Sending credentials on every request
• Switching between JWT and sessions inconsistently