JWT Authentication Concepts in Spring Boot

Traditional session-based authentication stores login state on the server, which doesn't scale cleanly across multiple server instances without shared session storage. JSON Web Tokens (JWT) solve this by putting the identity and claims directly inside a signed token that the client stores and sends with every request — the server verifies the signature and needs to keep no session state at all.

Structure of a JWT

A JWT is a string made of three Base64URL-encoded parts separated by dots: header.payload.signature. The header specifies the signing algorithm (e.g. HS256). The payload holds claims — data such as the subject (username), issued-at time, expiration time, and any custom claims like roles. The signature is computed over the header and payload using a secret key (or private key for asymmetric algorithms), and it's what lets the server detect if a token has been tampered with — without the signature verifying, the token is rejected outright.

The Stateless Authentication Flow

The typical flow has distinct steps: the client sends credentials to a login endpoint; the server verifies them and issues a signed JWT; the client stores the token (commonly in memory or a secure cookie) and attaches it as an Authorization: Bearer <token> header on every subsequent request; a security filter on the server extracts and validates the token on each request, and if valid, populates the SecurityContext with the authenticated user — all without querying a session store.

JWTs Are Not Encrypted by Default

A standard JWT (JWS — signed, not JWE — encrypted) is only signed, not encrypted — anyone can Base64-decode the payload and read its contents, they simply cannot modify it undetected without invalidating the signature. This means JWTs must never carry sensitive data like passwords, and expiration times must be kept short since a stolen valid token remains usable until it expires (unless a revocation/blacklist mechanism is added).

Example

public class JwtAuthFilter extends OncePerRequestFilter {

    private final JwtService jwtService;
    public JwtAuthFilter(JwtService jwtService) { this.jwtService = jwtService; }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
                                     FilterChain chain) throws ServletException, IOException {
        String header = request.getHeader("Authorization");
        if (header != null && header.startsWith("Bearer ")) {
            String token = header.substring(7);
            if (jwtService.isValid(token)) {
                String username = jwtService.extractUsername(token);
                var authToken = new UsernamePasswordAuthenticationToken(username, null,
                        jwtService.extractAuthorities(token));
                SecurityContextHolder.getContext().setAuthentication(authToken);
            }
        }
        chain.doFilter(request, response);
    }
}

// Example decoded JWT payload:
// { "sub": "asha@webnest.com", "roles": ["USER"], "iat": 1758441600, "exp": 1758445200 }

Request with valid, unexpired token -> reaches controller as authenticated user "asha@webnest.com"
Request with expired token -> 401 Unauthorized, SecurityContext left unauthenticated
Request with tampered payload -> signature check fails, token rejected before claims are trusted

Exercise

A teammate is about to make this mistake: Storing sensitive data (passwords, credit card numbers) inside JWT claims, forgetting that the payload is only Base64-encoded, not encrypted. Use Structure of a JWT to review the decision. Write a corrected implementation or design sketch that follows A JWT has three parts — header, payload, signature — and the signature lets the server detect tampering., then name one edge case you would check.

Quick quiz

Interview questions