2023/10/09

About the hot-off-the-press OAuth2 DPoP specification: https://datatracker.ietf.org/doc/html/rfc9449. DPoP is a “sender constraint”: a way of checking that the sender of an access (JW) token is the same as the entity to whom the access token was issued.

My simplified understanding of DPoP is as follows:

1. the client generates a private/public key pair
2. the client generates a request for an access token. The request includes:
   • the client’s public key
   • the the authorization endpoint’s URL
3. the client signs the request with the client’s private key
4. the authorization server validates the request (signature and all) and issues an access (JW) token including the thumbprint of the client’s public key. As is normal in OAuth2, the access token is signed by the authorization server’s private key.
5. the client generates a new proof including the client’s public key and the intended API endpoint, attaches that to the access token (remember, the access token also includes the thumbprint of the client’s public key). The client sends the proof and access token to the API.
6. The API validates
   1. the proof was signed by the client’s public key
   2. the client’s public key matches the thumbprint in the access token
   3. and the access key was signed by the and the authorization server’s public key

This seems much easier to manage than MTLS, which (I think) involves maintaining long-lived X509 certificates, signing infrastructure, and chains of trust.