JWT and OAuth2: Stateless Authentication in Practice

In plain words: authentication answers "who are you", authorization answers "what may you do, and may someone act on your behalf". JWT serves the first, OAuth2 the second — conflating them is the costliest misunderstanding in this article.

The classic setup keeps a ledger on the server after login (a session) and hands the browser a small ticket (JSESSIONID). The trouble starts at cluster scale: this request lands on node A, the next on node B, and B has never seen you. JWT flips where the ledger lives — identity is written into a token with an anti-forgery strip and carried by the client, so servers stop keeping books and only check the strip. The price is concrete: the token stays valid until it expires, so forcing a logout means maintaining your own blacklist.

Six terms, one line each (used throughout):

• Token: a self-proving credential string — a server reads it and knows who you are without touching the database
• Signature / verification: hash the content with a key to "stamp" it; verifying recomputes that hash with the same key, so one changed character breaks it
• Base64URL: an encoding (binary turned into URL-safe readable text), not encryption — anyone can decode it
• Claim: one field inside the payload, e.g. sub = who, exp = when it dies
• Bearer: the name of the HTTP auth scheme, and literally its rule — "whoever holds it gets in"
• Authorization code: OAuth2's one-time pickup slip, valid for seconds and useless as a key on its own

That comparison is the spine of this article: the left side is easy to control but hard to scale, the right side easy to scale but hard to revoke, and Section 5's dual tokens plus Section 11's sandbox exist precisely to patch the right side. The animation below parks the OAuth2 "pickup slip" route up front; come back to it when you reach Section 12.

After this article you should be able to answer three questions:

• When one character of a JWT's payload is changed, at which step does the server notice and by what mechanism?
• For "random 401s", should you suspect the algorithm first or mismatched per-instance keys? What is the cheapest way to tell?
• In third-party login, why must client_secret never appear in frontend code — and which hole opens if state is missing?

On a single machine, sessions are the easiest choice: after login the server keeps a session in memory or Redis and the browser holds a JSESSIONID cookie. The trouble starts at the cluster boundary: the next request may land on a node that has never seen that session.

One line of trade-off: sessions are easy to control but hard to scale; JWT is easy to scale but hard to revoke. For SPA + microservices, JWT's stateless nature usually wins.

A real JWT is three Base64URL segments joined by dots:

Split it and you get Header.Payload.Signature. The first two are merely Base64URL-encoded and anyone can decode them; here is each segment restored to JSON:

Laid flat, it becomes the anatomy chart below: three segments, three jobs — the first two are readable by anyone; only the third is the anti-forgery strip:

Walk the rule once more along the chart: join Header and Payload with a dot, digest the whole string to get the Signature; verifying recomputes that digest with the same key and compares. Section 2.1 then answers the more basic question — what exactly does that strip protect, and what does it not?

The signature proves the content was not tampered with: change sub or roles and it immediately fails to verify. But it does not keep the content secret, and it does not stop the token from being copied — whoever holds it can impersonate you. That's why JWT demands HTTPS and short lifetimes.

Signing falls into two families; choosing wrong bites you in microservices:

The key difference: leak an HS256 secret and anyone can forge tokens; with RS256 only the authorization server holds the private key and resource servers verify with the public one — even a compromised resource server cannot forge tokens. Prefer RS256 for microservices and open platforms.

Below is a hand-written issue/verify utility with JJWT. First the dependencies:

The full utility:

Part of the payload is standardized (RFC 7519), part is business-specific. Misuse causes security and compatibility pain:

A single token has a dilemma: short means constant logouts, long means a bigger theft window. The industry's answer is dual tokens:

• accessToken: short (say 15 minutes), sent with every request, so a leak has a small window.
• refreshToken: long (say 7 days), used only to obtain a new access token, never for business requests.

Four essentials of the refresh flow:

1. Access expires; the server returns 401; the frontend interceptor silently calls /auth/refresh.
2. The server verifies the refresh is valid and unrevoked, then issues a brand-new access + refresh pair.
3. Rotation: the old refresh is invalidated at once, so a stolen refresh works exactly once before the real user's next refresh fails and raises an alarm.
4. Logout: write the refresh's jti into a Redis blacklist with a TTL equal to its remaining life; check the blacklist before accepting.

The blacklist, token lifetimes and where the key lives all end up in configuration. The generator below turns "the minimum rows stateless auth needs" into checkboxes: tick only Redis for the smallest blacklist-capable snippet, then layer on logging, Actuator and per-environment profiles — read them against the refresh code above:

With a token in hand, you still need a filter to translate it into an identity Spring Security understands. Use OncePerRequestFilter so it runs once per request:

The most easily missed part of the filter code above is the failure path: an expired token raises nothing here — it is silently "translated" into an anonymous identity and passed down the chain. The stepper below walks an expired token through the filter frame by frame — step ③ raises the exception and step ⑤ quietly erases it:

Every row of the attack table can be caught at a different checkpoint. Here is the route a token takes from issuing to business code: signature, time, revocation, authorization — four gates, and missing any one opens an incident path. Poke each card to see which attack it answers:

The most important insight: OAuth2 is an authorization protocol; JWT is a token format — they are not the same thing. OAuth2 solves "how a third-party app accesses resources under a user's consent", and the token it issues may be a JWT or an opaque string.

The authorization-code flow is the safest mode for apps with a backend. Seven steps:

1. The frontend redirects the user to the authorization server with client_id, redirect_uri, scope, state.
2. The user logs in on the consent page and approves.
3. The server redirects back to redirect_uri with a one-time code and the returned state.
4. The backend exchanges code + client_secret for tokens (this happens server-side; client_secret never reaches the browser).
5. The backend receives the access token (and possibly a refresh and an id token).
6. The backend calls the resource server with the access token to fetch user info (e.g. GitHub /user).
7. The backend maps that user to a local account and issues its own session or JWT — third-party login now authenticates your app.

Key config items for wiring third-party login:

The most expensive trap in the "random 401" vocabulary deserves an animation — note the "restart fixed it" illusion at step ⑤; it fools people every day:

As you watch, line it up with the fix above: either distribute one jwt.secret to every instance, or move to RS256 so the private key stays with the issuer and every node shares the public key — "a restart fixed it" never means fixed; it means the request happened to land back on the instance that signed the token.

Sections 1-9 talked; this section lets you touch. Here is the analogy that should shape your first intuition about JWTs:

Turn Section 2's three segments into buttons you can press. This lab really assembles header.payload.signature and then takes it apart again in front of you:

Run those two and you get the key insight: issuing and verifying use the same key, the same algorithm, and opposite directions. Signing = stamp a digest of the first two segments with the key; verifying = recompute that digest with the same key and compare stamps. The server knows who you are without ever querying the database — that is precisely the "one signature check, no I/O" row of Section 1's table.

Two more labs cover the places where production actually breaks; switch to the arguments named below:

Section 9 listed traps in theory; now act them out one by one. Note that these three fail at different points, and in production they raise three different alerts:

Finally, look through the exception lens. What shape does a failed verification take in the response? It depends on how far your exception resolvers reach:

Three failure scenes replayed; now retype them on the command line. This console is wired to the same Java kernel in your browser — start with whoami to confirm an anonymous identity, then lab jwt through issue, verify and tamper, and finish with lab sec deny for the 401/403 fork:

The access token's lifetime is the one purely trade-off parameter in JWT: short and users complain, long and attackers cheer. The sandbox turns it into a spring you can pull; each of the three positions shows four metric groups side by side — the landing point of everything above:

Now put that "identity travels with the client" route back onto a real request — the picture below is exactly where Section 6's filter code sits in the chain, and the two boxes to watch are "Client calls with Bearer token" and "JWT filter parses and verifies": the client attaches the token itself, so the server performs no "who is this person" lookup per request (Section 5's blacklist only asks "has this ticket been reported lost" — an exception, not a ledger):

Section 8 gave the seven-step checklist; here it moves. Learn the analogy first and you will never recite the steps in the wrong order:

Pin down the three details interviewers love, using the animation as reference:

The matching Spring Boot configuration (Boot 3 / Spring Security 6 — copy property names verbatim):

This article is dense with vocabulary; what gets mixed up most is format versus protocol and credential versus scope. Play a round: click a term on the left, then its role in the chain — wrong picks get an explanation:

A warm-up on the boundary that people remember backwards, straight from Section 2:

Now a combined question threading Section 5's rotation, Section 7's attack surface and the three labs of Section 10:

Copy every snippet below straight into a search box — do not paraphrase or shorten it. Beginners stall in three places: verification failing, tokens expiring, and secrets being visible.

Row one of the error table (SignatureException) is familiar by now, but production has a more deceptive pair — an expired token meeting a missing authorization rule disguises a 401 as a 500. The stack below is real; don't peek at the answer:

Goal: about thirty lines that run through four outcomes — issue, verify, tamper, expire — leaving log evidence you can check line by line.

Step one, a minimal Maven project (only these three dependencies, Java 17):

Step two, the class (src/main/java/com/example/jwt/JwtDemo.java):

Run main. Expected output — four branches, one outcome each (spacing may vary slightly):

Acceptance checklist: ① say which segment changed in case (2) and why that alone breaks verification (answer: segment 2 changed while segment 3 stayed put, so the recomputed digest no longer matches the carried one); ② shorten the signing key to 31 bytes and the program dies at Keys.hmacShaKeyFor with IllegalArgumentException: Key length must be at least 256 bits for HS256 — you have reproduced row 5 of the error table; ③ state which production alert cases (3) and (4) each correspond to.

Change exactly one thing per run and the conclusion flips:

1. Swap .verifyWith(KEY) for a key that differs by only the last character. You will observe: every previously valid token now raises SignatureException, while startup and all other endpoints behave normally — the minimal reproduction of "inconsistent secrets across instances → random 401s". Fix in Section 9's second trap.
2. Make Duration.ofSeconds(-1) the only access-token lifetime, then re-run the Section 11 sandbox. You will observe: refresh traffic jumps from 0.9 to 3.4 QPS and users complain of constant logouts. That is the counter-proof that expiry is about loss windows, not comfort.
3. Hand-craft a token whose header is {"alg":"none","typ":"JWT"} with no third segment (Base64URL encode it and join as header.payload.), then send it to your endpoint. You will observe: modern JJWT rejects it inside parseSignedClaims with an algorithm error — but if you ever wrote "decode the payload and compare the timestamp myself" code, it would accept it. That gap is the algorithm-confusion surface of Section 7.
4. Add throw new ServletException(e) inside JwtAuthFilter's catch (JwtException e). You will observe: even permitAll public endpoints start returning 500/401 — one line reproduces the trap stated in Section 6.

Tip: after variant 1, reopen the prop lab's "Who wins" argument; both should tell exactly the same story.

Write yourself a "token health check" CLI (a plain main, no web layer needed) so any future JWT reveals its nature in three seconds.

Requirements:

• Given a token string, print all three segments decoded (Header / Payload as JSON, plus the signature's raw length)
• Print a standard-claims checklist: is exp present, how large is the iat→exp gap, is sub numeric, and are there suspected sensitive keys (name contains password / phone / idCard / email / secret)
• Verify with a supplied key and clearly separate three outcomes: pass / SignatureException / ExpiredJwtException; support --skew=60 to re-judge with 60 seconds of clock tolerance
• Detect and reject alg=none and anything outside HS256/RS256, printing a warning
• Optional: compare role claims against a built-in allowlist (ROLE_USER / ROLE_ADMIN) and highlight privilege-escalation strings such as role=admin&isSuper=true

Acceptance checklist: ① run it on the token from Level 1 and the report shows a 15-minute exp gap; ② flip any middle character and the tool reports SignatureException rather than crashing; ③ feed it a token with no exp and the report flags that as high risk; ④ feed it an alg=none token and it must refuse before verification, explaining why; ⑤ not one line of business code changes.