Broken authentication in an API means the service cannot reliably tell who is calling it, so an attacker can log in as someone else, reuse or forge a token, or reach a service that never asked for credentials at all. OWASP ranks it API2 in the API Security Top 10 2023 and rates its technical impact as severe, because a successful attacker acts as a legitimate user and the system usually cannot tell the difference. This guide goes deeper than the summary in the Top 10 API Security Risks: it sets out what the OWASP entry requires, how to harden login, recovery and token validation for APIs, how authentication works for service accounts, API keys and AI agents, and how to test and evidence the controls. It is for API developers, identity engineers and testers.
Key takeaways
- Every way in is an authentication endpoint. Login, token refresh, password reset, one-time code verification, magic links and mobile deep links all need the same brute force and lockout protection, and OWASP says so explicitly for recovery flows.
- Validate the token, not just its presence. Signature with an allowlisted algorithm, issuer, audience, expiry and token type must all be checked on every request; accepting
alg: noneor an expired JWT is listed by OWASP as a vulnerability in its own right. - OAuth is not authentication, and neither are API keys. OWASP's own wording: use OpenID Connect or an equivalent identity layer for users, and keep API keys for identifying client applications.
- Rate limits for authentication must be stricter and smarter than general limits. Count failures per account as well as per IP, and remember that GraphQL batching and parallel requests can multiply attempts inside one HTTP call.
- Service-to-service calls need authentication too. OWASP lists microservices reachable without authentication, or with weak or predictable tokens, as part of API2, so internal APIs and non-human identities are in scope.
What it is and who it applies to
OWASP describes the authentication mechanism as an easy target because it is exposed to everyone, and attributes the prevalence of the weakness to misconceptions about authentication boundaries and the complexity of implementation. The 2023 entry rates the risk as follows.
| OWASP factor | API2:2023 rating | What it means in practice |
|---|---|---|
| Exploitability | Easy | Credential lists, brute force tools and token tampering techniques are widely available |
| Prevalence | Common | Every API has several authentication paths, and each is implemented separately |
| Detectability | Easy | Missing lockout, weak validation and unauthenticated routes are simple to test for |
| Technical impact | Severe | Complete takeover of other users' accounts, data access and actions performed in their name |
Who it applies to: any organisation exposing REST, GraphQL, gRPC or mobile back-end APIs, whether public, partner or internal. The entry covers human users signing in through an API and machine callers such as microservices. The related weaknesses OWASP cites are CWE-307 (Improper Restriction of Excessive Authentication Attempts) and CWE-204 (Observable Response Discrepancy), the second being the root of user enumeration.
Where API2 ends: once a caller is correctly authenticated, deciding what it may touch is authorisation. Reaching another user's object is API1, reaching a function the caller should not use is API5. See the OWASP API Top 10 API1 Broken Object Level Authorization Guide and the OWASP API Top 10 API5 Broken Function Level Authorization Guide.
Structure and key requirements
The OWASP entry lists the conditions that make an API vulnerable. Each maps to a concrete engineering requirement and an OWASP ASVS 5.0 verification item that testers can check against.
| OWASP vulnerable condition | Engineering requirement | ASVS 5.0 anchor |
|---|---|---|
| Permits credential stuffing or brute force without CAPTCHA or lockout | Documented anti-automation per authentication endpoint, with per-account failure counting | V6.1.1, V6.3.1 |
| Permits weak passwords | Minimum length, check against common and breached passwords, no composition rules | V6.2.1, V6.2.4, V6.2.12 |
| Sends tokens or passwords in the URL | Credentials only in the Authorization header or request body, never the query string | REST Security Cheat Sheet guidance |
| Sensitive changes without confirming identity | Full re-authentication before changing email, phone, MFA or password | V7.5.1 |
Does not validate token authenticity; accepts alg: none; ignores expiry | Signature check with an algorithm allowlist, trusted key source, exp and nbf checks | V9.1.1, V9.1.2, V9.1.3, V9.2.1 |
| Plain text or weakly hashed passwords; weak encryption keys | Standard password hashing and strong, managed signing keys | V11 (cryptography) and the Password Storage Cheat Sheet |
| Microservices reachable without authentication or with predictable tokens | Every back-end component authenticates callers with individual service accounts, short-lived tokens or certificates | V13.2.1 |
Login and recovery flows
- Know every flow: OWASP's first prevention item is to inventory all authentication paths, including mobile, web and deep links that implement one-click sign-in. ASVS V6.3.4 requires that there are no undocumented pathways and that strength is enforced consistently across them.
- Uniform responses: the OWASP Authentication Cheat Sheet recommends one generic message for unknown user, wrong password and locked account, with the same status code and similar response time, so the API does not leak which accounts exist (CWE-204). Apply the same to registration and password reset.
- Password rules: NIST SP 800-63B-4 sets a minimum of 15 characters for single-factor passwords and 8 where the password is one factor of MFA, at least 64 characters allowed, a blocklist check on creation and change, and no composition rules or forced periodic changes.
- Recovery is login: reset and OTP verification endpoints get the same throttling and lockout as the login endpoint. ASVS V6.4.3 adds that resetting a forgotten password must not bypass enabled MFA, and V6.4.2 removes secret questions.
- Re-authentication: OWASP Scenario 2 shows why. A stolen token used to change the account email, followed by a password reset, gives full takeover. Require the current password or a fresh MFA step before changing email, phone number, MFA settings or password.
Throttling that actually works
- Per account and per source: count failures against the targeted account as well as the client IP, so rotating proxies do not reset the counter. NIST SP 800-63B-4 sets an upper bound of 100 consecutive failed attempts per authenticator before it is disabled; most APIs set a far lower threshold with increasing delays.
- Count operations, not requests: OWASP Scenario 1 shows a login mutation limited to three requests per minute being bypassed with GraphQL query batching, many login attempts in one HTTP request. Limit the number of authentication operations per request, or disable batching for authentication mutations. See the GraphQL Security Guide.
- Avoid lockout as a denial of service: the Authentication Cheat Sheet suggests exponential delays and letting a locked user recover through the reset flow, so an attacker cannot lock customers out at will.
- Layer signals for stuffing: the Credential Stuffing Prevention Cheat Sheet lists step-up MFA on risk, CAPTCHA on suspicious traffic, IP reputation and hosting-provider ranges, device and connection fingerprinting (such as JA3), breached password checks and user notification. See the Password Spraying and Credential Stuffing Defence Guide and the Rate Limiting and API Abuse Guide.
Token validation on every request
Most API authentication after login is a bearer token, often a JWT. RFC 8725 (JWT Best Current Practices) and ASVS chapter V9 set the checks a resource server should make before trusting any claim.
| Check | What to do | Failure it prevents |
|---|---|---|
| Signature and algorithm | Verify with an algorithm allowlist from server configuration, never from the token header; reject none | Unsigned or algorithm-confusion tokens (RFC 8725 section 3.1, ASVS V9.1.2) |
| Key source | Load keys only from the issuer's pre-configured JWKS; ignore jku, x5u and embedded jwk headers | Attacker-supplied keys (ASVS V9.1.3, RFC 8725 section 3.10) |
| Issuer and audience | Match iss to the expected issuer and aud to this API | Tokens minted for another service or tenant being replayed here (ASVS V9.2.3, V10.3.1) |
| Time | Enforce exp and nbf with small clock skew | Replay of expired tokens (ASVS V9.2.1) |
| Token type | Accept only access tokens for API calls, never ID tokens or refresh tokens; use explicit typing where the issuer supports it | Token confusion (ASVS V9.2.2, RFC 8725 sections 3.11 and 3.12) |
| Revocation | Short lifetimes, plus a jti denylist or introspection for logout and compromise | Stolen tokens staying valid for hours or days |
Validation must happen in a trusted back-end component (ASVS V7.2.1), and a failed validation must end the request. The LiteLLM MCP auth bypass is a clear example of the opposite: when key validation failed, the code fell back to an empty authentication object instead of rejecting the call, so any bearer token, even a single character, granted access to the MCP endpoint. See the JWT Security Guide and the Token and Session Security Guide.
Identity and NHI requirements
Much API traffic comes from non-human callers. API2 applies to them too, with different failure modes from human login.
| Caller | Typical API2 failure | Stronger pattern |
|---|---|---|
| Human user via app or SPA | Password only, no lockout, token in URL, long-lived tokens in browser storage | OpenID Connect with an identity provider, MFA, short-lived access tokens. See the OAuth 2.0 and OpenID Connect Guide. |
| Partner or customer integration | Static API key used as if it proved a user's identity, shared across environments, never rotated | OAuth client credentials with scoped, short-lived tokens; keys only to identify the client. See the API Keys vs OAuth Tokens Guide. |
| Internal microservice | "Inside the network" treated as authenticated; shared static secret between all services | mTLS (RFC 8705) or signed workload tokens per service, audience-restricted. See the Workload Identity Federation Guide. |
| CI/CD and automation | Long-lived personal tokens of an engineer embedded in pipelines | Federated workload identity and dedicated service accounts. See the Service Account Security Guide. |
| AI agent or MCP tool | Agent holds a broad static key; gateway accepts any bearer value or default keys | Delegated, user-bound, short-lived tokens with audience checks. See the AI Agent Authorisation Guide. |
- API keys identify clients, not users: OWASP states API keys should only be used for API client authentication. See the API Key Management Guide.
- Bind tokens to the caller where you can: sender-constrained tokens using mTLS certificate binding (RFC 8705) or DPoP (RFC 9449) stop a stolen access token from working on another client. See the Machine-to-Machine OAuth (Client Credentials) Guide.
- Validate tenant and issuer for every federated token: the Entra ID Actor Token flaw (CVE-2025-55241) arose because the Azure AD Graph API did not check which tenant an Actor token came from, so an impersonation token built in one tenant was accepted in any other. Microsoft fixed it within days and reported no known exploitation.
- No default credentials: ASVS V6.3.2 requires default accounts to be absent or disabled. Default master keys in gateways and admin APIs are a recurring source of full compromise.
Implementation steps
- Inventory authentication surfaces. From OpenAPI and GraphQL schemas, gateway configuration and traffic, list every route that issues, refreshes, verifies or resets credentials, and every route that accepts no credential. Unknown routes are where authentication is missing. See the OWASP API Top 10 API9 Improper Inventory Management Guide.
- Centralise user authentication. Move user sign-in to a standard identity provider using OpenID Connect, as OWASP advises ("don't reinvent the wheel"). The API then validates tokens rather than handling passwords.
- Write the authentication security documentation. ASVS V6.1.1 asks for documented rate limiting, anti-automation and adaptive response per flow. Record thresholds, windows, lockout duration and step-up triggers.
- Harden token validation in one shared library or gateway policy. Apply the six checks above, fail closed, and remove any code path that continues with an empty or anonymous identity after a validation error.
- Add re-authentication and MFA. Require MFA for administrative and high-risk users first (ASVS V6.3.3 at L2), then step-up for sensitive account changes (V7.5.1). Prefer phishing-resistant methods. See the Phishing-Resistant MFA Guide.
- Replace static machine secrets. Move service-to-service calls to mTLS or short-lived workload tokens, and partner integrations from shared keys to OAuth clients, one credential per consumer and environment.
- Test in a pilot first. Run new throttling and validation rules in report-only mode at the gateway, compare would-be denials with real traffic for one to two weeks, tune for mobile retries and shared corporate IPs, then enforce per API.
- Keep a rollback path. Deploy validation changes behind a feature flag or gateway policy version so a misconfigured audience or key set can be reverted in minutes. Never roll back by disabling signature checks.
Choosing an authentication pattern
| Pattern | Best fit | Trade-offs |
|---|---|---|
| OIDC with short-lived JWT access tokens | User-facing APIs, many services validating locally | Fast, stateless validation; revocation needs short lifetimes or a denylist |
| Opaque tokens with introspection | High-risk APIs needing immediate revocation | Revocation is instant; adds a call to the authorisation server per request or cache window |
| OAuth client credentials | Machine callers, partners | Scoped and expiring; client secret still needs vaulting and rotation, or use private key JWT |
| mTLS or DPoP sender-constrained tokens | Financial-grade and internal service mesh traffic | Stolen tokens are useless elsewhere; certificate and key lifecycle to run |
| Static API keys | Low-risk client identification, usage metering | Simple; no user identity, long-lived, easily leaked. Not for user authentication |
Small teams gain most from a managed identity provider, a strict JWT library and per-account throttling. Large organisations should standardise validation in shared middleware, publish one token profile and add sender-constrained tokens for internal and high-value traffic. See the MITRE ATT&CK T1528 Steal Application Access Token Guide.
Evidence and assessment
- Design evidence: the flow inventory, anti-automation documentation (V6.1.1) and the token profile.
- Automated tests: negative tests in CI for each protected route: no token, malformed token,
alg: none, wrong signature, wrong audience, wrong issuer, expired token, ID token instead of access token. Every case should return 401. - Throttling tests: scripted attempts against login, reset and OTP endpoints, including batched GraphQL operations and parallel requests, confirming lockout or delay triggers at the documented threshold.
- Authorised penetration testing: enumeration through response differences, reset flow abuse, token replay and unauthenticated internal routes. See the API Penetration Testing Guide.
Detection signals and metrics
| Signal or metric | Why it matters | Source |
|---|---|---|
| Failed logins per account and per source, by endpoint (login, reset, OTP) | Distinguishes brute force on one account from stuffing across many | Identity provider and gateway logs |
| Ratio of successful logins from hosting-provider or anonymising IP ranges | Credential stuffing success shows up here before account complaints | Gateway logs enriched with IP intelligence |
| Token validation failures by reason (signature, audience, expiry, type) | A spike in one reason points to tampering or misconfiguration | Gateway or middleware logs |
| Requests that succeeded with no credential on protected routes | Should be zero; any value is a live API2 finding | Gateway logs compared with the route inventory |
| MFA coverage of active accounts and of administrators | Shows exposure to stuffing that throttling alone will not stop | Identity provider reports |
| Share of machine callers on short-lived or sender-constrained credentials | Tracks retirement of static keys and shared secrets | NHI inventory, secrets manager |
User notification of suspicious attempts (ASVS V6.3.5) doubles as a detection channel. See the Secure Error Handling and Logging Guide.
Mapping to other frameworks
| Framework | Reference | Relevance to API2 |
|---|---|---|
| OWASP ASVS 5.0 | V6.1.1, V6.2.1, V6.3.1, V6.3.3, V6.4.3, V7.5.1, V9.1.1 to V9.2.3, V13.2.1 | Anti-automation, passwords, MFA, recovery, re-authentication, token validation, service authentication |
| MITRE CWE | CWE-307, CWE-204 | Excessive authentication attempts; observable response discrepancy |
| MITRE CAPEC | CAPEC-600, CAPEC-16, CAPEC-115, CAPEC-196 | Credential stuffing; dictionary attack; authentication bypass; session credential forging |
| NIST SP 800-53 Rev 5 | IA-2, IA-2(1), IA-5, IA-5(1), IA-8, IA-9, AC-7, SC-23 | User, non-organisational user and service authentication; authenticator management; unsuccessful logon attempts; session authenticity |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, DE.CM-03 | Identity and credential management; authentication of users and services; monitoring of activity |
| NIST SP 800-63B-4 | Sections 3.1.1, 3.2.2, 2.2, 2.3 | Password rules, throttling, reauthentication timeouts by assurance level |
| MITRE ATT&CK v20 | T1110.004, T1110.003, T1078, T1528, T1550.001 | Credential stuffing; password spraying; valid accounts; steal and use application access tokens |
| ISO/IEC 27001:2022 Annex A | 5.17, 8.5, 8.28 | Authentication information, secure authentication, secure coding |
| CIS Controls v8.1 | Control 6, Control 16 | Access control management (including MFA); application software security |
Common pitfalls
- Optional MFA on an exposed login API: in the 23andMe credential stuffing breach, reused passwords opened more than 18,000 accounts, MFA was optional and enabled by fewer than 22 percent of customers, and a sharing feature extended the exposure to almost 7 million people. More than a million login attempts in a single day had already caused an outage weeks earlier.
- Rate limiting by request, not by attempt: batching, parallel connections and IP rotation defeat simple per-IP request limits on login and OTP endpoints.
- Trusting the token without its context: checking the signature but not audience, issuer or tenant lets tokens from elsewhere be replayed.
- Long-lived static keys as identity: a key in a mobile app or public repository authenticates whoever finds it.
Practitioner checklist
- Inventory every authentication, recovery and token endpoint, and every route that accepts no credential.
- Delegate user authentication to a standard identity provider using OpenID Connect.
- Apply per-account and per-source throttling to login, reset and OTP endpoints, counting batched operations.
- Return uniform errors, status codes and timing for unknown users, wrong passwords and locked accounts.
- Enforce password length, breached-password checks and no composition rules, in line with NIST SP 800-63B-4.
- Validate signature, algorithm allowlist, key source, issuer, audience, expiry and token type on every request, failing closed.
- Require re-authentication before changing email, phone, MFA settings or password.
- Require MFA for administrators and high-risk accounts, preferring phishing-resistant methods.
- Authenticate every service-to-service call with mTLS or short-lived workload tokens; retire shared static secrets.
- Alert on stuffing patterns, validation failures by reason and unauthenticated success on protected routes.
Standards and references
- OWASP: API2:2023 Broken Authentication
- OWASP: API Security Top 10 2023
- OWASP: Application Security Verification Standard 5.0
- OWASP Cheat Sheet Series: Authentication
- OWASP Cheat Sheet Series: Credential Stuffing Prevention
- IETF: RFC 8725 JSON Web Token Best Current Practices
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- MITRE: CWE-307 Improper Restriction of Excessive Authentication Attempts
Related NHI Mgmt Group resources: Top 10 API Security Risks · API Security Guide · JWT Security Guide · Password Spraying and Credential Stuffing Defence Guide · OWASP API Top 10 API5 Broken Function Level Authorization Guide