Authentication: JWT, OAuth, sessions — the flaws we see most

> TL;DR: The most frequent implementation mistakes in JWT, OAuth 2.0, and classic sessions, with concrete examples and fixes.

Authentication, the number one weak link

Authentication is the most critical mechanism in any application. A flaw here gives direct access to user accounts. Despite the maturity of available libraries, we find implementation mistakes in the majority of applications we audit at CleanIssue.

JWT: the classic mistakes

Algorithm confusion (alg=none)

The JWT standard allows specifying the signing algorithm in the header. Some libraries accept "alg": "none" and consider the token valid without verifying any signature. The attacker forges a token with arbitrary claims.

Fix: explicitly specify the accepted algorithm server-side. Never trust the alg field from the token.

RS256/HS256 confusion

If the server uses RS256 (asymmetric) but also accepts HS256 (symmetric), the attacker signs the token with the public key (which is public) using HS256. The server verifies with the same public key and accepts the token.

No expiration

A JWT without an exp claim is valid indefinitely. If a token leaks (logs, URLs, cache), it remains exploitable forever. Worse: even with an exp, if the server doesn't check it, the token never expires in practice.

Fix: short-lived access tokens (15 minutes), refresh tokens with rotation and secure storage.

Weak secret

An HMAC secret like secret, password, or the company name. Tools like jwt-cracker test dictionaries of common secrets in seconds.

OAuth 2.0: implementation pitfalls

PKCE disabled

OAuth 2.0 with the Authorization Code flow without PKCE is vulnerable to authorization code interception. PKCE (Proof Key for Code Exchange) has been mandatory since OAuth 2.1 but many implementations don't enable it.

Lax redirect URI

If redirect_uri validation is too permissive (accepts subpaths or subdomains), an attacker redirects the authorization code to a URL they control. https://app.com.evil.com/callback might pass a filter that only checks for app.com.

Missing state parameter

Without the state parameter, the application is vulnerable to CSRF attacks on the OAuth flow. The attacker can link their own third-party account to the victim's account.

Overly broad scope

The application requests scope=admin when it only needs scope=read:profile. If the token leaks, the attacker has excessive privileges.

Classic sessions: the oversights

Insecure cookies

A session cookie without Secure, HttpOnly, and SameSite flags is vulnerable to interception (without Secure), theft via XSS (without HttpOnly), and CSRF attacks (without SameSite).

Incomplete invalidation

The user clicks Logout but the server-side session isn't destroyed. The cookie remains valid and usable. Even worse if sessions have no maximum lifetime.

Session fixation

The application doesn't regenerate the session ID after authentication. The attacker fixes a known session ID, the victim authenticates, the attacker uses the same now-authenticated ID.

Insufficient entropy

Predictable session IDs (based on timestamp, user ID, or a counter) allow an attacker to guess or brute-force active sessions.

Cross-cutting recommendations

Request your free CleanIssue diagnostic to audit your authentication system.

Key Takeaways