Skip to content
STANDARD

DPoP (RFC 9449) — Primer

DPoP (RFC 9449) provides sender‑constrained tokens with a per‑request proof JWT that binds the token to a client‑held key.

Visual representation of DPoP (RFC 9449) standard
← All standards

Why it matters

Standards reduce risk and vendor lock‑in. We implement this spec across our Studios and runtime so policy is portable.

Where it’s enforced

  • Gateway: pre‑execution gating (plan/schema pins, params/egress)
  • Shield: inline budgets/stream caps/content checks
  • PDP: decisions with constraints/obligations/TTL
  • IdP: passports, token exchange, consent/DPoP

How it works (high level)

DPoP (RFC 9449) binds tokens to a client key. Proof JWT header contains the public JWK; payload includes htu (URL), htm (method), iat, jti; RS requests include ath (access token hash). Issued tokens carry cnf.jkt.

DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IlJTMjU2Iiwia2lkIjoiIiwiamdrIjp7Imt0eSI6IlJTQSIsIm4iOiIuLi4iLCJlIjoiAQABIn19.eyJodG0iOiJQT1NUIiwiaHR1IjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vdG9rZW4iLCJpYXQiOjE3MDAwMDAwMDAsImp0aSI6InU0LWJpZCJ9..sig
mermaid
flowchart TD
  A[Client] -- DPoP proof --> TE[Token Endpoint]
  TE -->|cnf.jkt in token| AT[Access Token]
  A -- DPoP proof + AT --> RS[Resource Server]
  RS -->|verify sig, htm/htu, jti, ath| Allow

Servers commonly enforce replay windows on jti and may issue nonces. Resource calls MUST present a fresh proof per request.

References

← Resource Indicators (RFC 8707)
All standards
OAuth mTLS (RFC 8705) →