vulns.co
/
GKData.io MCP
ID / Identity

OAuth, DPoP, and mix-up

Review delegated identity and token flows for strict issuer, client, redirect, audience, and grant binding.

Guide 04 / 154 review notesUpdated 2026-10-11
Download .md ↓JSON ↗

The review

What to look for

Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.

  1. Map each binding

    Document issuer, client, redirect destination, state, nonce, code verifier, audience, and subject binding for the intended flow.

  2. Review callback decisions

    Confirm successful and error responses apply the same registered redirect and state validation.

  3. Review token acceptance

    Ensure the relying service validates issuer, audience, signature, expiry, and the grant context before account mapping.

  4. Check renewal boundaries

    Confirm refreshed authority stays within the original approved resource and consent scope.

What to produce

  • Grant binding map
  • Callback validation checklist
  • Token validation contract

Common mistakes

  • Accepting a claim without provenance
  • Validating only success redirects
  • Letting refresh expand resource authority

Continue the study

Reading & source context

Editorial notes above connect these references. Open each record for its original source and review date.

RFC 9700: Best Current Practice for OAuth 2.0 SecurityInternet Engineering Task Force / RFC Editor RFC 10017: OAuth 2.0 for Browser-Based ApplicationsInternet Engineering Task Force / RFC Editor n8n: refreshed authority must remain bound to the consented resourcen8n

Visual models

The identity provider authenticates a subject and binds issued claims to it. The relying application validates the issuer, audience, signature, and ownership binding before mapping to a local account. Failed validation is rejected.An identity claim must belong to the user ↗Approved grant context, including subject, client, permitted resources and actions, and a first-issuance or renewal request are both required inputs. Resolve trusted grant context and check that the grant and client are correct and requested authority remains within approval. Issue only bounded authority when all checks pass. Do not issue on mismatch or incomplete binding. Changing the approved authority requires a separate authorization decision; no automatic-consent loop is shown.Delegated authority stays within the approved grant ↗

Connected disclosures

Sign in with Apple failed to bind identity claims to the authenticated userApple GitHub OAuth consent failed across request-method semanticsGitHub Google device grants lost client and permission bindingGoogle

From the field toolkit

OAuth PKCE, DPoP, and mix-upplaybooks ↗OAuth & SSO Misconfigurationplaybooks ↗Modern OAuth and OIDCchecklists ↗Burp Suitetools ↗

Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.

Next skillGraphQL APIs →