Skip to content

DPoP: Add authorization code binding recommendation (dpop_jkt) #35

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
PieterKas wants to merge 2 commits into
base: pieterkas-dpop-extension
Choose a base branch
from
Open

DPoP: Add authorization code binding recommendation (dpop_jkt) #35

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
38ea8dc
Add authorization code binding recommendation (dpop_jkt)
PieterKas Oct 12, 2026
1452443
chore: format dpop-extension.mdx with prettier
Nov 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions specification/draft/dpop-extension.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,10 @@ DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6...

```

### Authorization Code Binding

MCP clients using the authorization code grant SHOULD bind the authorization code to their DPoP key, as described in [RFC 9449 Section 10](https://datatracker.ietf.org/doc/html/rfc9449#section-10).

### MCP Server Validation

MCP servers MUST validate DPoP proofs according to [RFC 9449 Section 4.3](https://datatracker.ietf.org/doc/html/rfc9449#section-4.3). Implementations conforming to this specification MUST verify that the `iat` claim is within ±5 minutes of the server's current time.
Expand Down Expand Up @@ -88,7 +92,6 @@ Example Authorization Server Metadata:
"token_endpoint": "https://auth.example.com/token",
"dpop_signing_alg_values_supported": ["ES256", "RS256", "PS256"]
}

```

**Note on Algorithm Selection:** While this specification does not mandate specific algorithms, authorization servers and clients SHOULD support modern, secure algorithms such as ES256 (ECDSA using P-256 and SHA-256). Implementations should avoid deprecated or weak algorithms. The security considerations of chosen algorithms are beyond the scope of this specification; implementers should consult current cryptographic best practices.
Expand Down Expand Up @@ -118,7 +121,6 @@ Below is an example of a decoded DPoP proof JWT suitable for an MCP request:
"crv": "P-256"
}
}

```

**JWT Payload:**
Expand All @@ -129,9 +131,8 @@ Below is an example of a decoded DPoP proof JWT suitable for an MCP request:
"htm": "POST",
"htu": "https://mcp.example.com/mcp",
"iat": 1699564218,
"ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo",
"ath": "fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQEo"
}

```

### Complete Request Example
Expand Down Expand Up @@ -202,6 +203,7 @@ Only asymmetric signature algorithms MUST be used for DPoP proofs. Symmetric alg
Replay protection options for stateless MCP servers are described in {{stateless-replay-protection}}. MCP servers requiring maximum replay protection SHOULD implement `jti` tracking despite the operational complexity. The trade-offs are discussed in detail in [RFC 9449 Section 11.1](https://datatracker.ietf.org/doc/html/rfc9449#section-11.1).

### DPoP Limitations

DPoP does not prevent token theft, but provides a mechanism that allows detection of replay attacks that utilise a stolen token. In addition, DPoP does not address confused deputy vulnerabilities or other authorization-level attacks. Consequently. implementations must maintain defense in depth by implementing all required security controls.

### Integration with MCP Security Model
Expand Down