Skip to content
All case studies
Digital Payments · 2026Critical · CVSS 9.8Confidential — anonymized

OAuth Token Confusion Account Takeover

A consumer wallet let users sign in with a major identity provider. We asked one question of the social-login endpoint: does it confirm the token was actually meant for this app? It did not. Armed with any genuine provider token — even one issued to a completely unrelated application — we could authenticate as the matching user and walk straight into their wallet. No password, no phishing of this brand, no victim interaction.

Duration
2 Weeks
Team
2 Application Security Operators
Scope
API Security Testing
Methodology
Grey-Box API Assessment / OWASP API Security Top 10

Attack narrative

Each phase references the MITRE ATT&CK technique used, with captured evidence.

  1. 01

    Reconnaissance

    T1595 — Active Scanning

    We mapped the authentication surface and isolated a server-to-server social-login route that swaps a third-party identity token for a first-party session.

    POST /auth/third-party-login (observed)
    — Request
    POST /auth/third-party-login HTTP/2
    Host: api.[REDACTED-CLIENT].example
    Content-Type: application/json
    Origin: https://app.[REDACTED-CLIENT].example
    {
    "audience": "<provider>",
    "idToken": "<GENUINE PROVIDER JWT — REDACTED>"
    }
    — Response
    HTTP/2 200 OK
    Content-Type: application/json
    {
    "token": "<FIRST-PARTY SESSION — REDACTED>",
    "user": { "id": "[REDACTED]", "email": "[REDACTED]" }
    }
  2. 02

    Analysis

    Improper JWT Audience Validation (CWE-347)

    The server validated the token signature against the provider’s public keys but ignored the audience claim that binds a token to one specific application. Signature-valid was treated as trusted, regardless of who the token was for.

    operator@proteqon: token-binding-check
    # Inspect which claims the server actually enforces
    $ auth-probe verify --token ./foreign_app_token.jwt --target api.[REDACTED-CLIENT].example
    [+] signature: VALID (issuer keys trusted)
    [!] audience (aud): NOT CHECKED <- token-binding broken
    [!] issuer (iss): NOT CHECKED
    verdict : any genuine provider token authenticates as its subject
    $
  3. 03

    Exploitation

    T1550 — Use Alternate Authentication Material

    Using a token legitimately issued to a different, unrelated application — but for the same person — we presented it to the wallet. The server resolved the subject and minted a full session for that user. Demonstrated against an operator-owned test identity only.

    operator@proteqon: cross-audience-replay
    # Token below was minted for an UNRELATED app, test identity only
    $ curl -s api.[REDACTED-CLIENT].example/auth/third-party-login -d @payload.json
    HTTP/2 200 OK
    [+] First-party session issued for foreign-audience token
    [+] Authenticated as test subject without its app or password
    $
  4. 04

    Impact

    T1078 — Valid Accounts

    A first-party session grants full account access: profile and contact data, linked funding instruments, transaction history, and the ability to move funds and change security settings. Impact was confirmed only against accounts we controlled.

Key vulnerabilities

Missing JWT Audience Validation on Social Login

The endpoint accepted any signature-valid identity token without verifying the audience matched this application, allowing cross-application token replay into full account takeover.

CriticalCVSS 9.8

Unvalidated Issuer Claim

The issuer claim was not strictly pinned, widening the set of tokens the endpoint would accept.

HighCVSS 7.4

No Replay / Nonce Binding

Absence of nonce binding allowed a captured token to be reused across sessions within its validity window.

MediumCVSS 5.9

Remediation

  1. 01

    Enforce strict audience validation: reject any token whose audience does not match the registered application client ID.

  2. 02

    Pin the accepted issuer and reject tokens from any other source.

  3. 03

    Bind tokens to a per-session nonce and reject replays.

  4. 04

    Alert on audience and issuer mismatches as a likely exploitation signal, and rotate sessions established before the fix.

Outcome

Audience enforcement deployed within the disclosure window. Confirmed fixed and existing sessions rotated.

None
Victim Interaction
Zero
Credentials Needed
< 7 Days
Time to Patch
1
Critical Findings

All client identities, infrastructure details, and timelines in this report have been anonymized and adapted to protect confidentiality. Technique identifiers reference the MITRE ATT&CK framework. All offensive actions described were performed within a pre-authorized rules-of-engagement window; no production data was destroyed and no live systems were harmed.

Start an engagement

Want this level of rigor on your systems?

Book a 30-minute scoping call with a senior engineer. You'll leave with a clear recommendation on scope, approach, and timeline.

Book a consultation contact@proteqon.com