Tokens and credentials
DPoP
Demonstrating Proof of Possession — binds a token to a key the client holds, so a stolen token alone is useless.
What DPoP means
DPoP turns a bearer token into one that only its rightful holder can use. The client generates a key pair, the token is bound to the public key, and every request carries a signed proof of possession of the private key. An attacker with the token but not the key has nothing.
Defined in: RFC 9449.
How it works
Mechanically: the client creates a key pair, sends the public key with the token request, and the authorization server binds the issued token to a thumbprint of that key. On each API call the client sends a DPoP proof — a short JWT signed with the private key, covering the HTTP method, the URI and a timestamp. The resource server checks the proof against the thumbprint in the token.
This addresses the attack that short token lifetimes only mitigate. Exfiltration through a log, a proxy, a compromised dependency or a misconfigured cache yields a token that cannot be replayed, because the key never travelled with it.
It matters most for machine and agent traffic, where tokens move through more infrastructure than a browser session ever does and where a single compromised service can otherwise replay any token it has observed.
The mistake people actually make
Generating a fresh key pair on every request, which defeats the binding entirely — the token is bound to one key and the proof is signed by another, so either the check fails or it was never really being made.
In Authreads
How this applies here
Machine and agent credentials are sender-constrained using DPoP, so a captured token carries no more privilege than the specific action it was issued for.
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.
Guides that go deeper
- OAuth and OpenID Connect for single-page apps: where tokens should live
- Refresh token rotation and reuse detection, explained
- DPoP implementation guide: sender-constrained tokens without mTLS
- Token theft and replay: how bearer tokens are stolen and how to limit the damage
- An OAuth 2.0 and OpenID Connect security checklist
- Identity for API and developer platforms
Related terms
Access token
A credential presented to an API to prove the caller is authorized, typically short-lived.
Machine identity
Credentials issued to a service, workload or agent rather than to a person.
Token exchange
Trading one token for another with different, usually narrower, privileges.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.