Why API Authentication Testing Matters for Bug Bounty

APIs are the backbone of every modern application. Mobile apps, SPAs, microservices, third-party integrations — they all authenticate through API endpoints. When that authentication breaks, attackers get direct access to user data, admin functionality, and backend systems without ever touching the web UI.

Broken authentication consistently ranks at the top of the OWASP API Security Top 10. Bug bounty programs pay premium rates for auth bypass findings because the impact is immediate: account takeover, data exfiltration, or privilege escalation to admin. If you can prove you bypassed authentication on a production API, you're looking at high to critical severity payouts.

Reconnaissance: Mapping API Authentication Surfaces

Before attacking auth, you need to understand what auth mechanisms the target uses and where they're enforced.

Identifying Auth Mechanisms

Start by cataloging every authentication method the API accepts. Most targets use more than one:

• Bearer tokens (JWT) — Look for Authorization: Bearer eyJ... headers. The eyJ prefix (base64 for {") confirms JWT format
• API keys — Check for keys in headers (X-API-Key, Authorization: ApiKey), query parameters (?api_key=), or request bodies
• OAuth 2.0 tokens — Identify the grant type by watching the token exchange flow. Authorization code, client credentials, and implicit flows each have different attack surfaces
• Session cookies — Some APIs still use cookie-based auth, especially when the API serves both web and mobile clients
• mTLS / certificate-based — Less common in public APIs but found in B2B and internal service-to-service communication

Endpoint Discovery

Auth enforcement is only as strong as its weakest endpoint. Find every endpoint the API exposes:

• Check for OpenAPI/Swagger docs at /swagger.json, /openapi.json, /api-docs, /v1/docs
• For GraphQL, send an introspection query to /graphql — if it returns the schema, you have a complete map of every query and mutation
• For gRPC, check if server reflection is enabled with grpcurl -plaintext target:port list
• Use Burp Suite's content discovery or ffuf with API-specific wordlists to find undocumented endpoints
• Check JavaScript bundles and mobile app binaries for hardcoded endpoint paths

JWT Attacks: The Most Common API Auth Vulnerability

JWTs are everywhere, and they're misconfigured more often than not. Here's what to test.

Algorithm Confusion (alg:none and RS256→HS256)

The classic JWT attack. If the server accepts "alg": "none", you can strip the signature entirely and forge any claims. Test with jwt_tool:

python3 jwt_tool.py <token> -X a

For RS256 to HS256 confusion: if the server uses RS256 (asymmetric) but also accepts HS256 (symmetric), you can sign a forged token using the server's public key as the HMAC secret. This works because the server uses the same key material for verification regardless of algorithm.

Weak Signing Secrets

Many JWTs are signed with weak or default secrets. Crack them offline:

hashcat -a 0 -m 16500 <token> /path/to/wordlist.txt

Common weak secrets include secret, password, the application name, and UUIDs that appear elsewhere in the application. Once cracked, you can forge tokens with any claims — admin access, different user IDs, elevated roles.

Missing Expiration and Claim Validation

Test whether the server actually validates critical claims:

• exp — Send an expired token. If it's accepted, tokens never expire
• iss / aud — Change the issuer or audience claim. If accepted, the server doesn't validate token origin
• sub / user_id — Change the subject to another user's ID. This is IDOR via JWT — if the server trusts the claim without cross-referencing, you have account takeover

JWK Injection and x5u/jku Abuse

Some JWT libraries allow the token itself to specify the verification key via the jwk header parameter or a URL (jku, x5u). If the server fetches and trusts these:

1. Generate your own RSA key pair
2. Host the public key at a URL you control
3. Set the jku header to your URL
4. Sign the token with your private key

The server fetches your public key and validates the signature you created — complete auth bypass.

OAuth and OIDC Token Attacks

OAuth implementations are complex, and complexity breeds vulnerabilities. Focus on the gaps between the spec and the implementation.

Redirect URI Manipulation

The redirect_uri parameter controls where authorization codes and tokens are sent. Test for:

• Open redirect on the redirect domain — If the target has an open redirect, chain it: redirect_uri=https://target.com/redirect?url=https://attacker.com
• Subdomain matching — Try redirect_uri=https://attacker.target.com if the validation only checks the parent domain
• Path traversal — redirect_uri=https://target.com/callback/../../../attacker-controlled-path
• Parameter pollution — Add duplicate redirect_uri parameters to confuse the parser

Token Leakage

OAuth tokens leak through multiple channels:

• Referrer headers — If the redirect page loads external resources, the token in the URL fragment or query string leaks via the Referer header
• Browser history — Implicit flow tokens in URL fragments persist in browser history
• Server logs — Authorization codes in query parameters get logged by web servers, proxies, and analytics tools
• Postmessage — SPAs using postMessage to pass tokens may have insufficient origin checks

Scope Escalation

Request more scopes than the application normally uses. Many OAuth servers don't validate requested scopes against the client's allowed scopes:

scope=openid profile email admin:write users:delete

If the server grants elevated scopes, you've escalated privileges through the OAuth flow itself.

GraphQL Authentication Bypass

GraphQL APIs consolidate multiple operations behind a single endpoint, which creates unique auth bypass opportunities.

Introspection-Guided Auth Testing

If introspection is enabled, query the full schema to find mutations and queries that should require authentication:

{
  __schema {
    mutationType {
      fields {
        name
        args { name type { name } }
      }
    }
  }
}

Then call each mutation without an auth token. Developers frequently protect the main queries but forget to gate admin mutations, internal tooling queries, or newly added fields.

Query Batching and Alias-Based Bypass

Some GraphQL rate limiters and auth checks only inspect the first query in a batch. Send multiple operations in a single request:

[
  {"query": "{ publicData { id } }"},
  {"query": "mutation { deleteUser(id: \"target\") { success } }"}
]

Alternatively, use aliases to call the same field multiple times with different arguments — useful for brute-forcing auth tokens or OTPs through a single request that bypasses per-request rate limits.

Field-Level Authorization Gaps

GraphQL resolvers may enforce auth at the query level but not at the field level. If you can access a user query, try requesting fields that should be restricted:

{ user(id: "self") { email passwordHash apiKey internalRole } }

gRPC Authentication Testing

gRPC services are increasingly common in microservice architectures. Their auth model differs from REST APIs.

Metadata-Based Auth Spoofing

gRPC uses metadata (similar to HTTP headers) for authentication. When a load balancer or API gateway sits in front of the gRPC service, it may inject auth metadata that the backend trusts implicitly:

grpcurl -plaintext -H "x-authenticated-user: admin" -H "x-user-role: superadmin" target:50051 service.AdminService/ListUsers

If the backend trusts these headers without validating them against the actual token, you can impersonate any user.

Reflection-Enabled Service Discovery

gRPC server reflection exposes all available services and methods — the equivalent of GraphQL introspection. Use it to find internal services that lack auth:

grpcurl -plaintext target:50051 list
grpcurl -plaintext target:50051 describe service.InternalService

Unary vs. Streaming Auth Checks

Some implementations validate auth on unary (single request-response) calls but skip validation on streaming RPCs. Test bidirectional and server-streaming methods separately — they may have weaker or missing auth enforcement.

API Key Attacks

API keys are the simplest auth mechanism and the most frequently leaked.

Key Discovery

• Client-side source — Search JavaScript bundles for API keys: grep -r "api[_-]key\|apikey\|authorization" *.js
• Mobile apps — Decompile APKs with jadx or use objection to hook API calls at runtime
• Public repositories — Search GitHub, GitLab, and Bitbucket for the target's domain combined with key-related terms
• Error messages — Trigger errors that leak keys in stack traces or debug output

Key Privilege Testing

Once you have a key, test what it can access. Many API keys have broader permissions than the application uses:

• Try admin endpoints with a regular user's API key
• Test write operations if the key was only used for reads
• Check if the key works across API versions — v1 may have weaker authorization than v2
• Test if the key works on staging or internal API subdomains

Practical Exploitation Chains

The highest-impact findings chain multiple auth weaknesses together.

Chain 1: JWT None Algorithm → Admin Takeover

1. Capture a valid JWT from a low-privilege account
2. Decode the payload — note the role and user ID claims
3. Set alg to none, change role to admin, strip the signature
4. Send the forged token to admin-only endpoints
5. If accepted: full admin access from an unprivileged account

Chain 2: OAuth Redirect + Token Theft → Account Takeover

1. Find an open redirect on the target domain
2. Craft an OAuth authorization URL with redirect_uri pointing to the open redirect, which forwards to your server
3. Send the link to a victim (or demonstrate the flow in your report)
4. Capture the authorization code or token when it arrives at your server
5. Exchange the code for an access token — you now have the victim's session

Chain 3: GraphQL Introspection → Hidden Mutation → Privilege Escalation

1. Run introspection to discover all mutations
2. Find an updateUserRole or setAdmin mutation not exposed in the UI
3. Call it with your own user ID and an elevated role
4. Verify your account now has admin privileges

Tools and Workflow

Writing High-Impact Reports

API auth bypass reports need to clearly demonstrate the impact. Include:

• Exact request/response pairs — Show the authenticated request, then the same request with the manipulated or missing token succeeding
• Impact demonstration — Don't just show the bypass; show what data or functionality you accessed. "I accessed 10,000 user records" hits harder than "the endpoint returned 200"
• Reproduction steps — Include curl commands or Burp request files that the triager can replay immediately
• Scope of exposure — How many endpoints are affected? Is it a single endpoint or a systemic auth failure?

Conclusion

API authentication testing is one of the highest-ROI skills in bug bounty. Every target has APIs, most have auth flaws, and the payouts for auth bypass are consistently at the top of the severity scale. Start with JWT analysis — it's the most common and most exploitable. Then expand to OAuth flows, GraphQL auth boundaries, and gRPC metadata. The tools are mature, the attack patterns are well-documented, and the targets are everywhere.

Focus on the gaps between what the spec says and what the implementation does. That's where the bounties live.