Tokens and credentials
Sender-constrained token
An access or refresh token bound to a key the client holds, so it cannot be used by anyone who merely copies it.
What Sender-constrained token means
A sender-constrained token is bound to a cryptographic key held by the client it was issued to. Each use must be accompanied by proof of that key, so a stolen token cannot be replayed from elsewhere. The two standard mechanisms are DPoP (RFC 9449) and mutual-TLS certificate binding (RFC 8705).
Defined in: RFC 9449 (DPoP) and RFC 8705 (OAuth mutual TLS).
How it works
The authorization server records a hash of the client's public key in the token (the cnf confirmation claim) or in its introspection response. The resource server compares that hash with the key used to prove possession on the current request — a DPoP proof JWT, or the client certificate on the TLS connection.
RFC 9700, the OAuth security best current practice, recommends sender-constraining as one of the two acceptable protections for refresh tokens issued to public clients, the other being rotation.
The mistake people actually make
Binding the token but storing the private key next to it. If both live in the same browser storage or the same config file, whoever steals one steals the other.
In Authreads
How this applies here
DPoP sender-constrained tokens are Available for machine and agent identity.
Every capability is listed on /roadmap as Available, In progress or Planned. Nothing is described as available here that is not listed as Available there.
Related terms
DPoP
Demonstrating Proof of Possession — binds a token to a key the client holds, so a stolen token alone is useless.
Bearer token
A token that grants access to whoever presents it, with no proof that the presenter is its intended holder.
Access token
A credential presented to an API to prove the caller is authorized, typically short-lived.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.