Skip to content
Authreads

Protocols and how-tos

DPoP implementation guide: sender-constrained tokens without mTLS

How DPoP proofs are built and checked, what the jti, htm, htu, ath and nonce claims are for, and the server-side checks that make it more than decoration.

The short answer

DPoP (RFC 9449) binds an access token to a key pair the client holds. For every request the client signs a short-lived JWT — the DPoP proof — covering the HTTP method, the URL, a unique ID and, at resource servers, a hash of the access token. The token carries a thumbprint of the public key, so a stolen token is useless without the private key.

Sources last reviewed .

What a proof contains

The proof is a JWT with typ dpop+jwt and the public key in the jwk header. Its claims (RFC 9449 section 4.2):

  • jti — a unique identifier, so the server can reject replays within the acceptance window.
  • htm and htu — the HTTP method and target URI (without query and fragment), so a proof for one request cannot be used on another.
  • iat — when it was created; servers accept only a short window.
  • ath — base64url SHA-256 of the access token, required when presenting the token to a resource server.
  • nonce — when the server has supplied one via the DPoP-Nonce header, to limit pre-generated proofs.

Server-side checks

  1. Parse the proof; require typ=dpop+jwt and an asymmetric algorithm from your allowlist.
  2. Verify the signature with the embedded public key and confirm the key contains no private parameters.
  3. Check htm and htu against the actual request, iat against your window, and jti against a replay cache for that window.
  4. At the token endpoint, issue a token whose cnf.jkt claim (or introspection response) holds the key's JWK SHA-256 thumbprint, and return token_type DPoP.
  5. At the resource server, require the Authorization: DPoP scheme, compute the thumbprint of the proof's key and compare it with the token's cnf.jkt, and check ath against the presented token.

Keys on the client

The protection is only as good as the key's confidentiality. In a browser, generate the key with WebCrypto as non-extractable so script can use it but cannot export it. On a server or agent, keep it in a secrets store or hardware module. DPoP does not stop an attacker who can run code inside the client from using the key there; it stops a token taken out of the client from working anywhere else.

DPoP or mutual TLS?

Mutual TLS certificate-bound tokens (RFC 8705) give the same property at the transport layer and suit service-to-service traffic inside infrastructure you control. DPoP works at the application layer, through proxies and CDNs that terminate TLS, and from browsers. Many deployments use mTLS internally and DPoP at the edge.

In Authreads

How this applies to Authreads

Sender-constrained tokens using DPoP are Available in Authreads for machine and agent identity.

Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.

Sources

Keep reading

Security

Token theft and replay: how bearer tokens are stolen and how to limit the damage

Use cases

Identity for AI agents: delegation, scoping and sender-constrained tokens

Protocols and how-tos

OAuth token exchange (RFC 8693) for delegation and impersonation

Glossary: DPoP · Access token · Machine identity

All 38 guides

Building on any of this?

Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.