Sender-constrained token
A sender-constrained token is a token whose recipient requires the presenter to prove possession of an associated secret or cryptographic key before accepting it.
What changes at the recipient
Someone holding a usable bearer token may be able to use it. A sender-constrained token requires additional proof from the person or application presenting it. OAuth mechanisms include certificate-bound access tokens using mutual TLS and Demonstrating Proof of Possession, or DPoP.
In DPoP, the authorization server binds an access token to a public key. The client presents a signed proof with its API request, and the resource server checks both the proof and its relationship to that token. The token must also remain valid for the requested access.
DPoP is not itself client authentication. It proves possession of the relevant private key. It does not give the application extra permissions.
The API has to enforce the binding
A DPoP-bound access token must be rejected when presented as an ordinary bearer token, even if the API supports both schemes. Otherwise, a caller could simply omit the proof to avoid the protection. RFC 9449 makes this rejection explicit.
For an integration review, confirm that requests with missing or invalid proofs fail at the receiving API. The feature’s presence in a product does not show that every client and API uses it.
Where the protection ends
When sender constraint is enforced correctly, stealing the token alone is not enough. An attacker who also obtains or can use the associated key may defeat that protection. The protection limits token replay, but it does not make a compromised endpoint safe.
Ask the integration owner how the associated keys are stored and who or what can use them. That determines what an attacker would need in addition to a stolen token.