JWT Architecture: HS256 vs RS256 Math & The 'None' Algorithm Exploit

✓ Last tested: May 2026 · Evaluated against RFC 7519 cryptographic specifications

1. Field Notes: The Global "None" Algorithm Breach

In 2024, I was contracted by a rapidly scaling FinTech startup. They had just launched a new decentralized finance portal. Three days after launch, they noticed that a random standard user account was successfully executing administrative dashboard commands, deleting server clusters and locking API endpoints.

I checked their authentication middleware. They were using JSON Web Tokens (JWT) for stateless authentication.

I dumped the compromised tokens and found the exact vulnerability that caused the breach. The attacker hadn't cracked their encryption keys or brute-forced the server. They had simply rewritten the token string.

Here was the fatal architectural flaw:

1. The RFC Standard: The official JWT specification (RFC 7519) originally included a testing algorithm called "alg": "none". If a token is generated with this algorithm, the signature portion of the token is left completely empty.
2. The Unrestricted Parser: The startup's backend engineers were using an outdated, loosely configured JWT validation library. They had failed to explicitly whitelist the algorithms the server was allowed to accept.
3. The Exploit: The attacker logged into their own standard account and received a valid token. They decoded the token locally, changed the "sub" (Subject ID) in the payload to the ID of the Admin, and changed the Header to "alg": "none". They deleted the cryptographic signature from the string and sent it back to the server.
4. The Bypass: The server read the header, saw the algorithm was set to "none", skipped the cryptographic verification entirely, and granted the attacker full administrative access.

We deployed an emergency patch in 10 minutes. We updated the verification code to strictly enforce: jwt.verify(token, publicKey, { algorithms: ['RS256'] }). The attack stopped instantly.

Authentication relies on strict mathematical boundaries. If you leave a window open for "testing algorithms," the internet will find it.

---

2. Architectural History: Stateful Sessions vs. Stateless JWTs

For decades, web application security relied on stateful session management. When a user logged in, the application server generated a random session identifier, stored it in a server-side database or shared memory cache (like Redis), and returned it to the client inside a cookie. On every subsequent request, the browser sent this identifier, prompting the server to query its database to verify the user’s identity.

As applications scaled to handle billions of requests across globally distributed microservices, this stateful model introduced major architectural bottlenecks:

• Database Read Scaling Bottlenecks: Every single API call triggered a mandatory database lookup to fetch the session state. Under peak load, the session database became the primary infrastructure bottleneck.

Stateful Session: [Client Request] ──> [Server] ──> [Query Redis Session DB] ──> [Verify Session]
Stateless JWT:    [Client Request + JWT] ──> [Server] ──> [Cryptographic Verification] ──> [Authorized]

Defined under RFC 7519, the JSON Web Token (JWT) solves these architectural scaling issues. A JWT is a self-contained, stateless credential. The server does not need to query a database to verify the user.

All necessary user metadata (roles, email, expiration limits) is packaged directly into a lightweight JSON payload and cryptographically signed. The server verifies the token instantly using only local mathematical logic.

---

3. Anatomy of a JWT: The Three Pillars

A JSON Web Token consists of three distinct segments separated by dot (.) characters:

Header.Payload.Signature

A. The Header (Metadata)

The header defines the format (typ) and the cryptographic algorithm (alg) used to sign the token:

{
  "alg": "RS256",
  "typ": "JWT"
}

B. The Payload (The Claims)

The payload contains the claims—key-value statements about the authenticated user and token configuration:

• iss (Issuer): The server domain that issued the token.
• sub (Subject): The unique identifier of the user.
• exp (Expiration Time): The exact Unix timestamp after which the token must be rejected.
• iat (Issued At): The exact Unix timestamp when the token was created.
• Custom Claims: Application-specific metadata like "roles": ["admin"].

C. The Signature (The Security Shield)

The signature is the cryptographic seal guaranteeing the token's integrity. It is computed by taking the Base64URL-encoded header, the Base64URL-encoded payload, a secret key, and running them through the algorithm:

$\text{Signature} = \text{RS256}(\text{Base64Url}(\text{Header}) + "." + \text{Base64Url}(\text{Payload}), \text{PrivateKey})$

If an attacker modifies the payload, the signature computed by the server will fail, and the request is blocked.

---

4. Cryptographic Signature Math: HS256 vs. RS256

Choosing the correct signing algorithm is a critical systems decision:

A. HS256 (Symmetric Cryptography)

HS256 uses a single Shared Secret Key for both signing and validation.

[Server: Sign with Secret] ──> JWT ──> [Server: Verify with SAME Secret]

• Pros: Exceptionally fast and computationally cheap.
• Cons: Any microservice that needs to verify the token must know the master secret key. If one peripheral microservice is compromised, the attacker steals the secret key and can forge administrative tokens for the entire architecture.

B. RS256 (Asymmetric Cryptography)

RS256 uses a Private Key (kept absolutely secure on the central authorization server) to sign the token, and a Public Key (distributed publicly) to verify it.

[Auth Server: Sign with Private Key] ──> JWT ──> [Microservices: Verify with Public Key]

• Pros: High architectural separation. Third-party APIs and microservices can verify tokens using your public key without ever gaining the ability to create or forge tokens.
• Cons: Computationally slower than HS256 due to heavy RSA mathematical overhead.

---

5. Storage Security: LocalStorage vs. HttpOnly Secure Cookies

Where should you store a JWT in the web browser?

1. LocalStorage (Dangerous)

• Mechanism: JavaScript reads/writes the token using localStorage.setItem(). The token is attached manually to the Authorization: Bearer <token> header.
• The Vulnerability (XSS): If an attacker successfully injects a malicious script into your page via a compromised third-party NPM library, the script can run localStorage.getItem() and steal your user’s token instantly, bypassing all security controls.

2. HttpOnly, Secure, SameSite Cookies (Secure)

• Mechanism: The server returns the JWT in a Set-Cookie header with strict security flags:

  Set-Cookie: token=jwt_value; HttpOnly; Secure; SameSite=Strict; Path=/api;
  

• The Protections:
  • HttpOnly: Guarantees that client-side JavaScript cannot read the cookie. Even if your page has an XSS vulnerability, the attacker cannot access the token.
  • Secure: Guarantees the cookie is only transmitted over encrypted HTTPS.
  • SameSite=Strict: Prevents the browser from sending the cookie during cross-site requests, protecting against Cross-Site Request Forgery (CSRF).

---

6. React & TypeScript JWT Context Lifecycle Architecture

Below is a production-ready React Context blueprint written in TypeScript.

It implements a secure client-side authentication provider. Assuming you are storing your JWTs securely in HttpOnly cookies, this architecture handles UI state management, decodes non-sensitive public claims, and triggers background refresh tokens seamlessly without exposing raw credentials:

import React, { createContext, useContext, useState, useEffect, useCallback } from 'react'

interface AuthUser {
  userId: string
  name: string
  roles: string[]
}

interface AuthContextType {
  user: AuthUser | null
  loginStateActive: boolean
  syncLoginState: (jwtPublicSegment: string) => void
  logout: () => void
}

const AuthContext = createContext<AuthContextType | undefined>(undefined)

export const AuthProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [user, setUser] = useState<AuthUser | null>(null)
  const [loginStateActive, setLoginStateActive] = useState<boolean>(false)

  // Decodes public claims sent by the server for UI routing (NOT for API auth)
  const decodeTokenClaims = (jwtPublicSegment: string): AuthUser | null => {
    try {
      // Decode standard base64 payload segment securely
      const decodedPayload = JSON.parse(atob(jwtPublicSegment.replace(/-/g, '+').replace(/_/g, '/')))
      return {
        userId: decodedPayload.sub || '',
        name: decodedPayload.name || '',
        roles: decodedPayload.roles || []
      }
    } catch {
      return null
    }
  }

  const syncLoginState = useCallback((jwtPublicSegment: string) => {
    const claims = decodeTokenClaims(jwtPublicSegment)
    setUser(claims)
    setLoginStateActive(true)
    // Local flag for multi-tab UI syncing only (No tokens stored!)
    localStorage.setItem('ui_session_active', 'true')
  }, [])

  const logout = useCallback(() => {
    setUser(null)
    setLoginStateActive(false)
    localStorage.removeItem('ui_session_active')
    
    // Tell server to destroy the HttpOnly cookie
    fetch('/api/auth/logout', { method: 'POST' })
  }, [])

  useEffect(() => {
    // On boot, check if UI thinks we are logged in, then verify with secure backend
    const active = localStorage.getItem('ui_session_active')
    if (!active) return

    fetch('/api/auth/verify-session', { method: 'POST' })
      .then((res) => {
        if (res.ok) return res.json()
        throw new Error('Session Invalid')
      })
      .then((data) => {
        if (data.publicClaims) syncLoginState(data.publicClaims)
      })
      .catch(() => logout())
  }, [syncLoginState, logout])

  return (
    <AuthContext.Provider value={{ user, loginStateActive, syncLoginState, logout }}>
      {children}
    </AuthContext.Provider>
  )
}

export const useAuth = () => {
  const context = useContext(AuthContext)
  if (!context) throw new Error('useAuth must be used within an AuthProvider')
  return context
}

---

7. Securely Verify and Debug Claims Offline

Decrypting, validating, and debugging malformed tokens manually can be tedious. If your client applications are returning token errors, inspect the payloads immediately inside a secure sandbox.

Use our advanced browser-based JWT Decoder Tool.

Built on absolute privacy principles:

• Zero Server Leakage: Your authentication tokens are parsed entirely inside your browser's local sandbox—they are never sent over the network, guaranteeing complete credential confidentiality.
• Intuitive Claims Highlighting: Automatically translates registered Unix timestamps (exp, iat) into localized readable dates.
• Error Auditing: Flags standard cryptographic vulnerabilities like missing padding and expired timestamps in real-time.

---

About The Author

Abu Sufyan is an enterprise systems engineer, web performance architect, and developer tooling designer based in Lahore, Punjab. He specializes in V8 execution benchmarking, React hook design, and semantic SEO architectures. You can review his open-source work on Github or check his personal portfolio website at abusufyan.xyz.