Justin explained DPoP to Jay with a metaphor about house keys, because Justin explained everything with metaphors when the underlying concept was simple but the name made it sound complicated.
"Demonstrating Proof of Possession," Justin said. "Terrible name. Simple idea. Imagine I give you a house key. A regular key. You can use it to open my front door. But if someone pickpockets you, they can also use it. The key works for whoever holds it. That's a bearer token."
Jay nodded. Bearer tokens were familiar territory. JWTs. API keys. Session cookies. Possession equaled authority. If you had the token, you were authorized. If someone stole the token, they were authorized too. The entire security model rested on the assumption that the token would not be intercepted, which was an assumption that the history of information security had thoroughly discredited.
"Now imagine a different kind of key," Justin continued. "This key only works if you also know a secret—a PIN, a fingerprint, something that's bound to you specifically. If someone steals the key, they can't use it, because they don't have the thing that proves they're you. The key is sender-constrained. It only works for the original holder."
"So the token is cryptographically bound to the client that requested it," Jay said, translating the metaphor into protocol.
"Exactly. The client generates a key pair. When it requests a token, it includes a proof—a signed JWT that demonstrates it holds the private key. The authorization server issues a token that's bound to that public key. When the client presents the token to a resource server, it also presents a fresh proof. The resource server verifies that the proof was signed by the same key the token is bound to."
Jay was drawing the flow on his notepad. Client generates key pair. Client requests token with proof. Server issues bound token. Client presents token plus proof. Resource server verifies binding. Four steps. Each step a cryptographic handshake that prevented the token from being useful to anyone except the entity that originally requested it.
"Stolen tokens become worthless," Jay said.
"Stolen tokens become worthless," Justin confirmed. "And in a world where agents are passing tokens between services, where tokens traverse networks that we don't fully control, where the attack surface includes every hop between every service—sender-constrained tokens aren't a luxury. They're a requirement."
Jay looked at his diagram. The flow was elegant. The cryptography was standard—RS256, ES256, EdDSA, nothing exotic. The implementation was straightforward. The security improvement was enormous. A stolen bearer token was a full compromise. A stolen DPoP token was a useless string.
"Why doesn't everyone do this?" Jay asked.
"Because bearer tokens are easier. Because DPoP requires the client to manage a key pair. Because most systems were designed when tokens were passed between humans clicking buttons, not between agents making thousands of API calls per hour."
"But we're not building for humans clicking buttons."
"No," Justin said. "We're building for agents. And agents can manage key pairs without complaining."
Jay committed the DPoP integration that week. The agents didn't notice the change. They generated key pairs, signed proofs, and presented bound tokens, all without friction, all without complaint. The tokens moved through the network, worthless to anyone who intercepted them.
The house key now only worked if you were the house.
The house key metaphor is the clearest explanation of DPoP I've ever encountered. I teach OAuth courses and I'm going to use this. Thank you, leash_chronicler.