JWT Authentication Flow — The 'alg: none' Attack

Every modern web application needs to answer one question on every single request: 'Do I know this person, and are they allowed to do this?' The naive answer is to store a session in a database and look it up on every request. That works fine for a single server handling a few hundred users — but the moment you scale horizontally, add microservices, or need a mobile app talking to multiple APIs, that session-database approach becomes a bottleneck and an architectural headache.

JWT — JSON Web Token — was designed to solve exactly this problem. Instead of storing state on the server, you encode the user's identity and permissions directly into a signed token and hand it to the client. The client sends it back with every request, and the server can verify it cryptographically in microseconds without touching a database. The server went from being a stateful gatekeeper to a stateless verifier. That shift has enormous implications for scalability, microservices architecture, and cross-domain authentication.

By the end of this article you'll understand exactly how a JWT is structured, how the full login-to-protected-request flow works under the hood, why the signature makes it tamper-proof, how to implement it correctly in Java, and — critically — the mistakes that create real security vulnerabilities even when the basic flow looks right. Whether you're building your first authenticated API or preparing for a system design interview, you'll walk away with a complete mental model of JWT authentication.

What is JWT Authentication Flow?

JWT (JSON Web Token) authentication is a stateless authentication mechanism. When a user logs in, the server creates a signed JSON token containing the user's identity and permissions. The client stores it (typically in localStorage or an HTTP-only cookie) and sends it with every subsequent request via the Authorization header. The server verifies the signature — no database lookup needed. The flow is: Login → Server issues JWT → Client stores JWT → Client sends JWT in request header → Server verifies JWT → Server grants or denies access.

JWTs are base64url-encoded and signed, not encrypted by default. That means anyone with the token can read the payload — so you never put secrets like passwords inside. What makes it trustable is the cryptographic signature appended to the payload. If the payload is tampered with, the signature verification fails.

package io.thecodeforge.auth;

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import javax.crypto.SecretKey;
import java.util.Date;

public class JwtExample {

    // Never hardcode secrets in production; use environment variables or a vault
    private static final SecretKey SECRET_KEY = Keys.hmacShaKeyFor(
            "my-super-secret-key-at-least-256-bits-long-for-hs256".getBytes()
    );

    public static String createToken(String userId, String role, long ttlMillis) {
        Date now = new Date();
        Date expiration = new Date(now.getTime() + ttlMillis);
        return Jwts.builder()
                .setSubject(userId)
                .claim("role", role)
                .setIssuedAt(now)
                .setExpiration(expiration)
                .signWith(SECRET_KEY, SignatureAlgorithm.HS256)
                .compact();
    }

    public static void main(String[] args) {
        String token = createToken("user-1234", "admin", 3600000);
        System.out.println(token);
    }
}

Token Creation: Signing the Right Way

Creating a JWT securely involves three artifacts: the header, the payload, and the signature. The header typically contains the algorithm (HS256, RS256) and token type (JWT). The payload contains registered claims (iss, sub, exp, iat, jti) and custom claims like roles. The signature is computed by combining the base64url-encoded header and payload with a secret (HMAC) or private key (RSA/ECDSA).

Two broad signing categories: symmetric (HS256) and asymmetric (RS256, ES256). Symmetric uses the same key for signing and verification — fast but requires sharing the secret between issuer and verifier. Asymmetric uses a private key to sign and a public key to verify — you can safely distribute the public key to any verifying service. In production, asymmetric is preferred because you can rotate the private key without touching every verifier.

The most common mistake: using HS256 when the verifying party should not have the signing secret. For example, a mobile app that verifies its own JWT should never hold the HMAC secret — attackers reverse-engineer the app.

package io.thecodeforge.auth;

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;

import java.security.KeyPair;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.util.Date;

public class JwtSigner {
    // Generate a keypair for RS256 — do this once and reuse
    private static final KeyPair KP = Keys.keyPairFor(SignatureAlgorithm.RS256);
    private static final PrivateKey PRIVATE = KP.getPrivate();
    private static final PublicKey PUBLIC = KP.getPublic();

    public static String createToken(String userId, long ttl) {
        return Jwts.builder()
                .setSubject(userId)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + ttl))
                .setIssuer("auth.io.thecodeforge.com")
                .signWith(PRIVATE, SignatureAlgorithm.RS256)
                .compact();
    }

    public static boolean verifyToken(String token) {
        try {
            Jwts.parserBuilder()
                .setSigningKey(PUBLIC)
                .build()
                .parseClaimsJws(token);
            return true;
        } catch (Exception e) {
            return false;
        }
    }
}

How Verification Works without State

Stateless verification is the killer feature of JWT. The verifying server does the following: parse the token, decode the header, check the algorithm against a whitelist, decode the payload (but don't trust it yet), recompute the signature using the expected key, and compare with the provided signature. If they match, you trust the payload claims. If not, reject.

Stateless means no database call for each request. That's a massive win for latency and scalability. However, you lose the ability to force-logout a user — a compromised token remains valid until expiry. To mitigate, use short-lived tokens (15 minutes) combined with a refresh token mechanism. The refresh token is stored server-side (or in a database) and can be revoked.

Stateless verification also requires the verifying service to possess the correct key at all times. With RS256 and JWKS endpoint, you can fetch the public key on startup and cache it. If the key rotates, the token signed with the old key stays valid until its expiry — no interruption.

package io.thecodeforge.auth;

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.Claims;
import java.security.PublicKey;

public class JwtVerifier {

    private final PublicKey publicKey;

    public JwtVerifier(PublicKey publicKey) {
        this.publicKey = publicKey;
    }

    public Claims verify(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(publicKey)
                .build()
                .parseClaimsJws(token)
                .getBody();
    }

    public String extractUserId(String token) {
        return verify(token).getSubject();
    }

    public boolean hasRole(String token, String role) {
        return verify(token).get("role", String.class).equals(role);
    }
}

Common JWT Vulnerabilities and How to Avoid Them

JWTs are secure only if implemented correctly. Top vulnerabilities:

1. Algorithm Confusion: The attacker changes 'alg' from 'RS256' to 'HS256'. If your server uses the public key as the HMAC secret (which is a string), it will verify the token using the public key as the HMAC key — the attacker can sign tokens with the public key. Fix: never derive the verification key from the token; always hardcode the expected algorithm.
2. 'none' Algorithm: Some libraries accept 'alg: none' and skip verification. Fix: reject tokens where the algorithm is 'none' or not in the whitelist.
3. Weak Secret: HS256 with a short or predictable secret. Fix: use a key of at least 256 bits generated from a cryptographically secure random source.
4. Token Replay: A stolen token can be used until expiry. Fix: use short-lived access tokens (15 min) and implement refresh token rotation (issue a new refresh token each time, invalidate the old one).
5. Payload Secrets: Developers put passwords or credit card numbers in the payload. The payload is base64 encoded, not encrypted. Fix: never store sensitive data in JWT payload. If needed, use JWE (JSON Web Encryption) to encrypt the payload.

package io.thecodeforge.auth;

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.security.Keys;
import java.security.Key;

public class SecureJwtConfig {
    // Whitelist algorithms explicitly
    private static final String ALLOWED_ALGORITHM = "RS256";
    private static final Key PUBLIC_KEY = loadPublicKey();

    public boolean verifyTokenSecurely(String token) {
        try {
            Jwts.parserBuilder()
                .requireAlg(ALLOWED_ALGORITHM) // enforce algorithm
                .setSigningKey(PUBLIC_KEY)
                .build()
                .parseClaimsJws(token);
            return true;
        } catch (Exception e) {
            return false;
        }
    }

    private static Key loadPublicKey() {
        // Load from secure store — never from token header
        return Keys.hmacShaKeyFor(
            System.getenv("JWT_SIGNING_SECRET").getBytes()
        );
    }
}

JWT in Microservices: Token Propagation and Revocation

In a microservices architecture, JWT shines because each service can independently verify the token without contacting a central auth store. The authentication service issues a token scoped to a user. Downstream services extract the token from the incoming request (often via a gateway) and verify it.

Challenge: revocation. Stateless tokens cannot be invalidated server-side without a blacklist. Best practice: short access token TTL (15 minutes) plus a long-lived refresh token stored in the auth service's database. When the user logs out, you invalidate the refresh token. The access token will expire soon. For immediate revocation, you can maintain a distributed blacklist (Redis) of jti claims, but this reintroduces state.

Another challenge: token size. With multiple claims and signatures, tokens can grow beyond 2KB. In HTTP headers, that's fine. But if you pass tokens via URL query parameters (bad practice), you'll hit length limits.

Token propagation across service boundaries should use the same signed token — never create a new token per service, as that requires each service to trust the other. Use the existing JWT and let each service verify it with the same public key.

package io.thecodeforge.gateway;

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.security.Keys;
import jakarta.servlet.Filter;
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletRequest;
import jakarta.servlet.ServletResponse;
import jakarta.servlet.http.HttpServletRequest;
import java.security.PublicKey;

public class JwtGatewayFilter implements Filter {
    private final PublicKey publicKey;

    public JwtGatewayFilter(PublicKey publicKey) {
        this.publicKey = publicKey;
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
        HttpServletRequest httpReq = (HttpServletRequest) request;
        String authHeader = httpReq.getHeader("Authorization");
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            throw new SecurityException("Missing or invalid Authorization header");
        }
        String token = authHeader.substring(7);
        Claims claims = Jwts.parserBuilder()
                .setSigningKey(publicKey)
                .build()
                .parseClaimsJws(token)
                .getBody();
        // Attach claims to request context for downstream services
        httpReq.setAttribute("claims", claims);
        chain.doFilter(request, response);
    }
}

Session Tokens vs. JWT: Why You Reach for Asymmetric Keys

You've heard the debate. Sessions live on the server. JWTs live on the client. The real difference is failure mode. Session tokens require a database lookup every request. That lookup adds latency and couples your auth to a centralized store. For a single web app, that's fine. For a microservice mesh, it's a nightmare. JWT flips the model: the server signs a token with a private key, and any service can verify it with a public key. No shared database, no synchronous lookups. The price? You can't revoke a JWT without a deny list. That's why you choose asymmetric signing (RS256 or ES256). Symmetric signing (HS256) forces every service to hold the same secret—one leak and your entire system is compromised. Asymmetric keys let you distribute trust. Your auth service holds the private key. Every other service only needs the public key. If one service gets pwned, the attacker still can't mint new tokens. This is not academic. I've cleaned up after teams that used HS256 across six services. Don't repeat that mistake.

// io.thecodeforge
const jwt = require('jsonwebtoken');
const fs = require('fs');

// In production, load from a secure vault, not the filesystem
const PUBLIC_KEY = fs.readFileSync('./keys/public.pem', 'utf8');

function verifyJwt(token) {
  try {
    const payload = jwt.verify(token, PUBLIC_KEY, {
      algorithms: ['RS256']
    });
    return { valid: true, payload };
  } catch (err) {
    if (err.name === 'TokenExpiredError') {
      return { valid: false, reason: 'expired' };
    }
    if (err.name === 'JsonWebTokenError') {
      return { valid: false, reason: 'malformed_or_invalid_signature' };
    }
    return { valid: false, reason: 'unknown' };
  }
}

// Usage: every microservice calls this on incoming requests
console.log(verifyJwt('some.jwt.here'));

Implementation in Node.js with Express: Where Most Teams Bleed

The code is the easy part. The mistakes are in the flow. Here's what a production JWT authentication middleware looks like. Notice what is missing: no database calls, no session stores. You check the token, verify the signature, and extract the user ID from the 'sub' claim. That's it. But here's the trap: you must set an 'exp' claim with a short expiration (15 minutes for access tokens, 7 days for refresh tokens). Do not set 'exp' to a year. I've seen tokens with a 5-year expiration in a SaaS product. The engineer thought it was 'convenient' for users. The attacker who stole that token thought it was 'convenient' too. The second trap: never trust the token's 'role' or 'isAdmin' claim without also verifying it against a backend store if the role changes at runtime. Otherwise, a user can change their role in the JWT if they forge the signature. Use 'sub' and look up roles per request if you need real-time authorization. The code below shows a secure, minimal Express middleware that follows this pattern. One job. One validation. No surprises.

// io.thecodeforge
const jwt = require('jsonwebtoken');

// PUBLIC_KEY loaded from environment or vault
const PUBLIC_KEY = process.env.JWT_PUBLIC_KEY;

function authMiddleware(req, res, next) {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing or malformed Authorization header' });
  }

  const token = authHeader.split(' ')[1];

  try {
    const decoded = jwt.verify(token, PUBLIC_KEY, { algorithms: ['RS256'] });

    // Only trust the subject (user ID) from the token
    req.userId = decoded.sub;

    // Never trust roles from the token if they can change at runtime
    // Look up roles from your database here if needed
    next();
  } catch (err) {
    if (err.name === 'TokenExpiredError') {
      return res.status(401).json({ error: 'Token expired. Please refresh.' });
    }
    return res.status(403).json({ error: 'Invalid token.' });
  }
}

module.exports = authMiddleware;