DEV Community

Cover image for JWT Authentication, Explained by Actually Running One (No Setup)
Parveen Kumari
Parveen Kumari

Posted on

JWT Authentication, Explained by Actually Running One (No Setup)

#ai #security #webdev #api

Decode a real JWT, exploit alg:none in 30 seconds, and learn exactly what to test in your own auth — all in your browser against a live sandbox

Most JWT tutorials show you a diagram and call it a day. This one is different: every example runs against a real sandbox API in your browser, so you can decode tokens, exploit alg: none, and watch a server actually reject (or accept) what you throw at it.

If you've ever signed off on a JWT implementation without being 100% sure what the library is doing under the hood — this is for you.

What a JWT actually is

A JWT (JSON Web Token, pronounced "jot") is a signed, self-contained string that carries claims about a user, used to authenticate requests.

Self-contained is the magic word. The server doesn't need to look up a session — the token itself has the user info plus a signature proving it hasn't been tampered with. The server just verifies the signature and trusts the claims.

** The three parts

A JWT is three Base64URL-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWxpY2UifQ.sig_bytes_here
↑ header              ↑ payload                              ↑ signature
Enter fullscreen mode Exit fullscreen mode

Decode the first two and you get JSON.

Header:

{ "alg": "HS256", "typ": "JWT" }
Enter fullscreen mode Exit fullscreen mode

Payload (claims):

{
  "sub": "user-123",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1712345678,
  "exp": 1712349278
}
Enter fullscreen mode Exit fullscreen mode

Signature: HMAC-SHA256(header.payload, secret) — or an RSA/ECDSA signature for asymmetric algorithms.

⚠️ Anyone can decode a JWT. The payload is signed, not encrypted. Never put secrets (passwords, credit-card numbers, anything you'd be sad to see in a log) in a JWT.

Standard claims (RFC 7519)

Claim Meaning
iss Issuer — who created the token
sub Subject — who the token is about (user ID)
aud Audience — who the token is for
exp Expiration — Unix timestamp after which the token is invalid
nbf Not Before — Unix timestamp before which it's invalid
iat Issued At — when it was created
jti JWT ID — unique identifier for revocation

Plus any custom claims your app needs: role, tenant_id, permissions, and so on.

Run a login and get a real token

Here's the login request — POST /auth/login against the public sandbox:

POST https://demo.totalshiftleft.ai/auth/login
Content-Type: application/json

{
  "email": "demo@totalshiftleft.ai",
  "password": "demo123"
}
Enter fullscreen mode Exit fullscreen mode

Response:

{
  "access_token": "eyJhbGciOi...",
  "refresh_token": "eyJhbGciOi...",
  "expires_in": 900
}
Enter fullscreen mode Exit fullscreen mode

Want to actually run it and see the real token come back?
👉 Run this live in your browser — no signup

Then call a protected endpoint with the token:

GET https://demo.totalshiftleft.ai/api/v1/me
Authorization: Bearer eyJhbGciOi...
Enter fullscreen mode Exit fullscreen mode

Drop the Authorization header and you get a 401. That's the whole flow.

How the server verifies a token

On every request, the server runs through this checklist:

  1. Read the Authorization: Bearer <token> header.
  2. Split the token into header, payload, signature.
  3. Check alg matches the expected algorithm — reject none explicitly.
  4. Recompute the signature over header.payload using the secret/public key.
  5. Compare the computed signature to the provided one — in constant time.
  6. Parse the payload. Check exp is in the future and nbf is in the past.
  7. Optionally check iss, aud, jti against a revocation list.
  8. Only now treat the claims as trusted.

Skipping step 3 or 4 is the classic vulnerability — and several major libraries have shipped it.

Seven JWT vulnerabilities you should be able to test for

1. alg: none. Attacker changes the header to {"alg":"none"}, drops the signature, and forges any payload. Only works if the library accepts none. Reject it explicitly.

2. alg confusion (RS256 → HS256). Attacker flips alg from RS256 to HS256 and signs with the server's public key as if it were the HMAC secret. Naive libraries verify it as HMAC against the public key (which is, well, public) and accept it. Always pin the algorithm server-side. Never trust the header's alg.

3. Weak HMAC secrets. 8-character secrets can be brute-forced offline from a single valid token. Use ≥256 bits of entropy.

4. Long expirations. exp 30 days out means a stolen token is usable for 30 days. Access tokens should live ~15 minutes; long-lived refresh tokens do the rest.

5. No revocation. JWTs are stateless by design — which makes revocation hard. Mitigations: short expiry + refresh tokens, jti blacklist, or per-user "tokens issued before X are invalid" timestamps.

6. Storing JWTs in localStorage. Vulnerable to XSS. Use httpOnly, Secure, SameSite cookies for browser clients.

7. Generous clock skew. A 5-minute window is fine. A 24-hour window is a vulnerability.

What to actually test

If you're writing tests for a JWT-protected API — or QA-ing one — here's the checklist I actually use.

Happy paths

  • Login with valid creds → 200 with access_token, refresh_token, expires_in.
  • Protected endpoint with valid token → 200.
  • Token includes expected claims (sub, email, role).

Authentication negatives

  • No Authorization header → 401.
  • Wrong scheme (Basic instead of Bearer) → 401.
  • Malformed token (missing a segment) → 401.
  • Expired token (exp in the past) → 401 with a distinguishable code (e.g., TOKEN_EXPIRED).
  • Not-yet-valid token (nbf in the future) → 401.
  • Token signed with the wrong secret → 401.
  • alg: none token → 401. This is a security-critical test — most JWT libraries have shipped this bug at some point.
  • Tampered payload (modify a claim, keep the old signature) → 401.

Authorization negatives

  • Valid token with role: user hitting an admin endpoint → 403.
  • Valid token but tenant_id doesn't own the resource → 403 or 404 (document which — both are defensible).

Edge cases

  • Token issued by a different iss → 401.
  • Token with aud not matching this API → 401.
  • Token with a huge payload (10 KB of custom claims) → should work or 413.
  • Multiple Authorization headers → document the behavior (most stacks take the first).

Refresh flow

  • Valid refresh token → new access + refresh pair; old refresh token now invalid.
  • Re-using an old refresh token → 401 (detects token theft).
  • Refresh token after the user changes their password → 401. A password change should invalidate tokens.

Pen-tester checklist (steal this)

  1. Copy the JWT, change alg to none, remove the signature — does it still work? If yes: critical bug.
  2. If alg is RS256, try resigning with HS256 using the server's public key — does it work? If yes: critical bug.
  3. Decode the payload. Anything that shouldn't be there (passwords, PII, internal IDs that leak architecture)? Report as data exposure.
  4. Does the token include a jti? If not, revocation is likely not implemented.
  5. Set the system clock past exp — does the token still work? Clock-skew vulnerability.

Try it yourself

Reading about JWTs is fine. Watching one fail validation in real time is better.

The full lesson — with a runnable login, a real protected endpoint, and the alg: none exploit live against a sandbox — is here, free, no signup:

👉 Learn JWT Authentication — runnable lesson

It's part of a free 32-lesson API testing course covering REST, GraphQL, SOAP, OAuth2, contract testing, and AI-assisted testing. Every lesson has a runnable example against a live sandbox: totalshiftleft.ai/learn.

What's your favorite JWT footgun in production? Drop it in the comments — I'm collecting them for the next post on refresh-token rotation patterns.

Top comments (0)