Authentication is how server-side code establishes who the caller is before any authorization decision is made. For an attacker it is the highest-value target in the application: break it and you usually get account takeover or full administrative access outright, with no further chaining required. This section covers application-level weaknesses in that logic (credentials, federated logins, multi-factor checks, sessions, and tokens) as implemented in the target's own code and dependencies.

Authentication answers "who are you?"; authorization (access control) answers "what may you do?". They break differently and are attacked differently, and this subtree is strictly the former. When you can become another user, you rarely need to defeat access control at all.

Where it breaks (your openings)#

Authentication code is fragile because it stitches together cryptography, state, and third-party protocols. The recurring openings:

• Security decisions made on attacker-controlled input. Token headers (alg, kid), redirect parameters, and the Host header are all client-modifiable, yet are frequently trusted before identity is proven. This is the richest seam, covered in JWT algorithm confusion.
• Skipped checks in complex protocols. OAuth, OIDC, and SAML have many mandatory-but-optional-looking parameters. Relying parties that code the happy path routinely drop state, nonce, audience, signature, or redirect_uri validation, each a foothold.
• Home-grown primitives. Predictable reset tokens, hand-rolled session IDs, and custom "remember me" cookies reintroduce solved problems you can exploit.
• Missing throttling and lifecycle. Login, OTP, and reset endpoints without rate limits invite brute force; sessions that never rotate or expire enable fixation and replay.

Attack methodology#

Work an authentication surface in this order:

1. Map every entry point. Password login, SSO/social login, API tokens, password reset, account invite, "remember me", step-up/MFA, and any legacy or mobile endpoint. Each is a separate trust boundary and a separate attack.
2. Find the credential of trust. Determine exactly what the server checks on each request (a session cookie, a JWT, a SAML assertion) and where it is verified. The verifier is your primary target; everything else is reconnaissance toward it.
3. Attack the verifier. Tamper with the token or assertion: swap algorithms and key-selection headers, strip or null signatures, replay across users and sessions, and test whether issuer, audience, expiry, and binding are actually enforced.
4. Attack the flows around it. For federated logins, go after redirect_uri/state/nonce handling and audience checks; for resets and invites, go after token entropy, lifetime, single-use, and host-header poisoning; for MFA, go after throttling, step ordering, and fallback paths.
5. Escalate and persist. Turn a foothold into impact: forge an admin identity, pivot across tenants, or capture long-lived tokens. Confirm whether privilege changes and logout actually invalidate prior sessions.

Account-takeover testing manipulates real identities, so contain it to systems in scope and avoid locking out or destroying genuine accounts during brute-force and reset work.

Attack avenues#

• JWT algorithm confusion: forge JSON Web Tokens by abusing the attacker-controlled alg header (none, RS256 to HS256 key confusion) or jwk/jku/kid key selection, so a token with chosen claims passes verification.
• OAuth redirect misconfiguration: steal authorization codes or tokens through weak redirect_uri validation and missing state/nonce, including login CSRF against the relying party.
• Password reset and invite tokens: seize accounts via predictable, long-lived, reusable, or host-header-poisoned reset and invitation links.
• Session fixation: plant a known session identifier that is not regenerated on login, then ride the victim's authenticated session.
• Weak OTP and MFA throttling: brute-force or bypass second factors where one-time codes have weak entropy, no rate limiting, or broken ordering checks.