hydra
hydra copied to clipboard
ory
Support dPoP (OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer)
Preflight checklist
- [X] I could not find a solution in the existing issues, docs, nor discussions.
- [X] I agree to follow this project's Code of Conduct.
- [X] I have read and am following this repository's Contribution Guidelines.
- [ ] This issue affects my Ory Cloud project.
- [ ] I have joined the Ory Community Slack.
- [ ] I am signed up to the Ory Security Patch Newsletter.
Describe your problem
DPoP (for Demonstrating Proof-of-Possession at the Application Layer) is an application-level mechanism for sender-constraining OAuth access and refresh tokens. It enables a client to prove the possession of a public/private key pair by including a DPoP header in an HTTP request.
New w3c standards like solid-oidc mandates dPoP, to enable decentralized and secure identities. It will be great if hydra supports it.
Describe your ideal solution
Supporting dpop
Workarounds or alternatives
Is it possible to layer over hydra for it? Any little guidance will be appreciated.
Version
Current
Additional Context
No response
Yes to this! Hydra and its admin have almost everything to be a headless solid-oidc provider. (referring to the rfc, and an implementation).
The missing parts are these two steps:
- Validates DPoP Token Signature The OP extracts the client’s public key from the DPoP header (at header.jwk). It confirms that the DPoP token has a valid signature. If not, the OP must reject the request with a 400 HTTP status and invalid_dpop_proof error code.
- Converts the DPoP public key to a JWK thumbprint Currently the DPoP token contains a JWK public key, but before we place it inside the access token, it needs to be converted into a JWK thumbprint. Our JWK thumbprint looks more like:
9XmwK8mQ3H5-PnzAt3lFHzWBW_v5QhYynezbbit4kC8
So adding dPoP support would be greatly appreciate, I can not really help on the implementation… So hope these references are helpful to do triage.
Thanks
DPoP support would indeed be a great addition. A PR would be highly appreciated!*
*Given the complexity and security relevance here, a short design doc to outline the planned changes will be needed as a first step.
