Demonstrating Proof of Possession (DPoP, RFC9449) is a new proposed standard (https://datatracker.ietf.org/doc/html/rfc9449) for OAuth2 that constraints who can use the access token for when calling an OAuth2-protected endpoint. It's an important standard for improving the security of OAuth2 tokens when migrating to from mTLS to OAuth2 deployments.
It works by the client sharing a JWK thumbprint when requesting an access token. The client then signs a DPoP proof (containing request URL and HTTP method) and provides it as HTTP header when accessing the OAuth2-protected API.
The resource server (or APISIX in this case) then uses the cnf claim from the OAuth2 Token Introspection response to verify the proof signature. It can then reassure the OAuth2 access token wasn't stolen by a MITM, but is in fact used by the very same party that requested the token. Usage is not enforced by the server, but up to the OAuth2 client to enable.
Description
Demonstrating Proof of Possession (DPoP, RFC9449) is a new proposed standard (https://datatracker.ietf.org/doc/html/rfc9449) for OAuth2 that constraints who can use the access token for when calling an OAuth2-protected endpoint. It's an important standard for improving the security of OAuth2 tokens when migrating to from mTLS to OAuth2 deployments.
It works by the client sharing a JWK thumbprint when requesting an access token. The client then signs a DPoP proof (containing request URL and HTTP method) and provides it as HTTP header when accessing the OAuth2-protected API. The resource server (or APISIX in this case) then uses the
cnf
claim from the OAuth2 Token Introspection response to verify the proof signature. It can then reassure the OAuth2 access token wasn't stolen by a MITM, but is in fact used by the very same party that requested the token. Usage is not enforced by the server, but up to the OAuth2 client to enable.Are there plans to support DPoP?