Broken Authentication

Broken Authentication encompasses a broad class of vulnerabilities in API authentication mechanisms that allow attackers to compromise authentication tokens, exploit implementation flaws, or assume other users' identities. This vulnerability class is ranked second in the OWASP API Security Top 10 due to its prevalence and the severity of its consequences—complete account takeover and unauthorized access to all resources associated with the compromised identity.

API authentication is inherently more complex than traditional web application authentication because APIs are designed for programmatic access, often supporting multiple authentication schemes simultaneously (API keys, OAuth 2.0 tokens, JWTs, mutual TLS certificates). Each scheme has its own failure modes, and the stateless nature of most API architectures means that token-based authentication must be implemented correctly at every endpoint without relying on server-side session state.

Common manifestations include weak password policies on token generation endpoints, missing brute-force protections on login endpoints, insecure token storage or transmission, improper JWT validation (accepting unsigned tokens, using weak algorithms, failing to validate issuer/audience claims), and flawed OAuth 2.0 implementations that allow authorization code interception or token leakage through redirect URI manipulation.

Attackers exploit broken authentication through several technical vectors. Credential stuffing attacks use automated tools to test large databases of leaked username-password pairs against API login endpoints. Without rate limiting or account lockout mechanisms, attackers can test thousands of credentials per minute. JWT-based attacks involve manipulating the token header to change the algorithm from RS256 to HS256 (algorithm confusion), setting the algorithm to "none" to bypass signature verification entirely, or exploiting weak HMAC secrets through offline brute-force attacks.

OAuth 2.0 implementation flaws provide another attack surface. Insecure redirect URI validation allows attackers to steal authorization codes by registering redirect URIs with subtle variations (subdomain takeover, open redirects, path traversal). Missing PKCE (Proof Key for Code Exchange) implementation in public clients enables authorization code interception attacks. Token endpoint misconfiguration may allow client credential theft or token exchange abuse.

Session management weaknesses in API authentication include tokens that never expire or have excessively long lifetimes, refresh tokens stored in client-accessible locations (localStorage, cookies without appropriate flags), missing token revocation mechanisms that allow continued access after password changes or account deactivation, and Bearer token transmission over unencrypted channels. API key authentication often suffers from keys embedded in client-side code, shared across environments, or transmitted in URL query parameters where they are logged by proxies and web servers.

• Complete account takeover allowing attackers to impersonate any user and access all their resources and permissions
• Mass credential compromise through automated credential stuffing enabling access to thousands of accounts
• Privilege escalation when administrative accounts are compromised through authentication bypass
• Data exfiltration at scale when authentication bypass provides unrestricted API access without per-user rate limits
• Persistent unauthorized access through stolen long-lived tokens that remain valid even after the victim changes their password
• Supply chain compromise when API keys or service account credentials are exposed in client-side code or public repositories

1. Implement multi-factor authentication (MFA) for all user-facing authentication endpoints and enforce strong password policies with minimum length, complexity requirements, and breach database checks using APIs like Have I Been Pwned.
2. Deploy rate limiting and account lockout mechanisms on all authentication endpoints. Use progressive delays, CAPTCHA challenges, and temporary account lockouts after a configurable number of failed attempts. Implement these controls at the API gateway level.
3. Use short-lived access tokens (5-15 minutes) paired with secure refresh token rotation. Store refresh tokens server-side with binding to the original client and implement absolute token expiration. Invalidate all tokens on password change or account compromise.
4. Validate all JWT claims rigorously: verify the signature algorithm matches expectations (reject "none" and unexpected algorithms), validate issuer, audience, expiration, and not-before claims. Use asymmetric algorithms (RS256, ES256) for JWTs shared between services.
5. Implement OAuth 2.0 with PKCE for all public clients, strict redirect URI validation (exact match, no wildcards), and short-lived authorization codes. Use the authorization code flow with PKCE instead of the implicit flow for single-page applications.
6. Enforce TLS 1.2+ for all API communications and transmit tokens exclusively in HTTP headers (Authorization header), never in URL query parameters. Set appropriate cookie flags (Secure, HttpOnly, SameSite) for cookie-based token storage.
7. Implement comprehensive authentication event logging including successful logins, failed attempts, token refreshes, and logouts. Alert on anomalous patterns such as logins from new geographic locations, multiple failed attempts, or concurrent sessions from different IPs.
8. Conduct regular credential rotation for API keys and service account tokens. Use secret management solutions (HashiCorp Vault, AWS Secrets Manager) and implement automated key rotation with zero-downtime deployment strategies.

Begin authentication testing by inventorying all authentication endpoints and supported authentication methods. Use Burp Suite to intercept authentication flows and document token formats, lifetimes, and transmission methods. Test each authentication mechanism independently: for JWT-based auth, use tools like jwt_tool to test algorithm confusion (alg:none, RS256-to-HS256), signature bypass, claim manipulation, and key brute-forcing. For OAuth flows, test redirect URI validation by modifying the redirect_uri parameter with subdomain variations, path traversal, and URL encoding tricks.

Perform credential stuffing simulations using tools like Hydra or custom scripts with rate measurement to determine if the API has effective brute-force protections. Test account lockout behavior, progressive delay implementation, and whether lockout mechanisms can be bypassed through IP rotation or header manipulation (X-Forwarded-For). Verify that password reset flows do not leak information about registered accounts and that reset tokens are single-use, time-limited, and bound to the requesting session.

Test token lifecycle management by verifying tokens expire at the expected time, refresh tokens are rotated on use and old refresh tokens are invalidated, all tokens are revoked on password change, and concurrent session limits are enforced. Use Burp Sequencer to analyze token randomness and detect predictable patterns. For API key authentication, verify that keys are not exposed in client-side code, URL parameters, or error messages, and that key rotation does not cause authentication bypasses during the transition period.