Sender-Constrained Tokens & DPoP
Overview
Keymate binds access tokens to the cryptographic identity of the requesting client using Demonstrating Proof-of-Possession (DPoP) as defined in RFC 9449. This section explains the enforcement model, protection mechanisms, and integration points that make stolen tokens unusable without the corresponding private key.
When to Read This Section
Read this section when you need to understand how Keymate prevents token theft and replay, how DPoP proofs are validated at the gateway, or how DPoP-bound sessions work in the Admin Console.
Who Should Start Here
- Security engineers implementing or evaluating token protection
- Platform teams configuring gateway-level DPoP enforcement
- Architects designing sender-constrained token flows
Key Topics
- DPoP proof validation and token binding via
cnf.jkt - Replay protection through distributed JTI tracking
- Downgrade attack detection for Bearer-scheme misuse
- Admin Console DPoP-bound session management
Representative Journeys
- I want to understand how DPoP enforcement works → DPoP Enforcement Model
- I want to understand how the Admin Console binds sessions → Admin Console DPoP Sessions
- I want to understand replay and downgrade protection → Replay, Downgrade & Abuse Protection
Recommended Reading Order
- DPoP Enforcement Model
- Replay, Downgrade & Abuse Protection
- Admin Console DPoP Sessions
- API Gateway DPoP Enforcement
- Enforcer Identity Trust Model