Authentication and JWT Bypass

In this Vulnerability Explain post we look at Authentication Bypass, with a strong focus on JSON Web Tokens (JWT) since they are everywhere in modern apps and APIs. When authentication can be sidestepped, an attacker becomes any user they like – including the admin. We will cover the common bypass patterns, how to test for them, and how to build auth that actually holds up.

What is Authentication Bypass?

Authentication Bypass is any flaw that lets an attacker access protected functionality without valid credentials, or as a different user than they really are. With JWTs, the bypass usually comes from weak token verification rather than guessing passwords.

A JWT is a signed token the server hands you after login; you send it back on each request to prove who you are. The catch is that the token is only as trustworthy as the verification behind it. If the server forgets to check the signature properly, an attacker can simply forge a token that says “I am the admin” and walk in.

How does Authentication Bypass work?

Authentication bypasses come in several flavors. With JWTs specifically, the most common chains look like this:

• The alg=none Trick
  • The attacker changes the token header to alg none and strips the signature; a careless server accepts the unsigned token as valid.
• Algorithm Confusion
  • The server expects an RS256 token verified with a public key, but the attacker switches to HS256 and signs with that public key as the secret.
• Weak or Leaked Secrets
  • If an HS256 token is signed with a weak secret, it can be brute-forced offline and used to mint valid tokens.
• Claim Tampering
  • When signatures are not enforced, the attacker edits claims like user, role, or exp to escalate privileges or extend sessions.
• Logic and Flow Flaws
  • Beyond JWTs, forced browsing to post-login pages, missing checks on multi-step flows, and broken password-reset logic all bypass authentication.

The recurring theme is a server that issues tokens correctly but verifies them loosely. Authentication only works when every request is validated as strictly as the login that created it.

How a JWT bypass works: setting alg to none and stripping the signature yields a forged admin token.

Tools and Techniques for Authentication Bypass Testing

Auth and JWT testing combines token manipulation with secret-cracking and logic review. A few purpose-built tools make the JWT side fast.

Manual Testing Methodologies

• Token Decoding and Editing – Decode the JWT, change claims such as role or user id, and replay it to see if the server still trusts it.
• alg and Header Attacks – Test alg none, swap RS256 to HS256, and try the kid header for path traversal or SQL injection.
• Session and Flow Testing – Force-browse to authenticated pages, replay old tokens after logout, and probe each step of multi-stage logins.
• Password Reset Review – Check reset tokens for predictability, reuse, and host header poisoning that leaks the link to an attacker.

Automated Scanning Tools

• jwt_tool – Swiss-army knife for testing JWT flaws, including alg none and algorithm confusion.
• JWT Editor / Attacker – Burp extensions for manipulating and signing tokens during testing.
• Hashcat – Cracks weak HS256 signing secrets offline.
• Burp Suite Scanner – Helps detect broken access control and session handling issues.

Authentication Bypass Protection Mechanisms

Best Practices for Secure Coding

• Verify Signatures Strictly
  • Description: Always validate the JWT signature and pin the expected algorithm server side.
  • Benefits: Defeats alg none and algorithm-confusion attacks.
  • Implementation Tip: Never let the token’s own header choose the algorithm; hard-code it in your verification call.
• Use Strong Secrets and Keys
  • Description: Use long, random HS256 secrets or proper asymmetric keys, rotated regularly.
  • Benefits: Prevents offline brute-forcing of the signing secret.
  • Implementation Tip: Store secrets in a vault, never in source code or client-side files.
• Validate Claims and Lifetimes
  • Description: Check exp, iat, aud, and iss, and keep token lifetimes short.
  • Benefits: Limits the window and scope of any stolen or forged token.
  • Implementation Tip: Maintain a server-side revocation or rotation strategy for sensitive sessions.

Best Practices for Organizations

• Centralize Authentication
  • Use a vetted identity provider or library rather than rolling your own.
  • Apply multi-factor authentication on sensitive accounts and actions.
• Enforce Access Control Everywhere
  • Re-check authorization on every request, not just at login.
  • Test protected routes with no token, expired tokens, and other users’ tokens.
• Continuous Auth Testing
  • Include JWT and session checks in automated security testing.
  • Run regular penetration tests focused on authentication and access control.

Top Authentication Bypass payloads used by Security Researchers

As a security researcher, knowing the most common payloads helps you detect and prevent these attacks. Use this knowledge ethically and only on systems you are authorized to test. Some sample payloads are shown below.

// alg=none attack - header changed, signature removed
{"alg":"none","typ":"JWT"}
// eyJhbGciOiJub25lIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

// Tampered claim to escalate privileges
{"user":"attacker","role":"admin","exp":9999999999}

// Algorithm confusion (RS256 -> HS256) with jwt_tool
jwt_tool TOKEN -X k -pk public.pem

// Cracking a weak HS256 secret offline
hashcat -a 0 -m 16500 token.jwt wordlist.txt

Real-World Example: Admin Takeover via alg=none

An API issued RS256-signed JWTs and used a JWT library in a permissive mode that honored the algorithm named in the token header.

A tester took their normal token, changed the header algorithm to none, removed the signature, and set the role claim to admin. The server accepted the unsigned token because it trusted the header, granting full administrative access without any password or key.

The fix pinned verification to RS256 and rejected unsigned tokens outright. The lesson with authentication is unforgiving: a token is only proof of identity if you verify it the same way every single time, with an algorithm you chose – not one the attacker picked.

Vulnerable and secure code of Authentication Bypass

The following example shows the contrast between vulnerable and secure code for Authentication Bypass. It helps you see how the flaw creeps into real code and the changes that shut it down.

🥺 Vulnerable Code:

// Vulnerable: trusts the algorithm named in the token header
const jwt = require("jsonwebtoken");

function verifyToken(token) {
  // No algorithms list -> alg:none and RS256->HS256 confusion both work
  return jwt.verify(token, publicKey);
}

• Without an explicit algorithms list, an attacker can supply alg none or switch algorithms.
• A forged token claiming role admin may be accepted as valid.

😎 Secure Code:

// Secure: pin the algorithm and validate the claims
const jwt = require("jsonwebtoken");

function verifyToken(token) {
  const payload = jwt.verify(token, publicKey, {
    algorithms: ["RS256"],      // never trust the header's alg
    issuer: "https://auth.example.com",
    audience: "example-api",
    maxAge: "15m",
  });
  return payload;
}

• Pinning algorithms to RS256 defeats both alg none and algorithm-confusion attacks.
• Checking issuer, audience, and lifetime limits the scope of any stolen or forged token.

Conclusion

Authentication is unforgiving: a token only proves identity if you verify it the same strict way on every request. Pin the expected algorithm rather than trusting the token’s own header, use strong secrets or proper key pairs, validate claims and keep lifetimes short, and re-check authorization on every protected route. Lean on a vetted identity provider instead of rolling your own, add multi-factor authentication on sensitive actions, and test your endpoints with missing, expired, and other users’ tokens.