-
Notifications
You must be signed in to change notification settings - Fork 329
RFC7523: Store the payload of the supplied JWT for later use in token hook in Hydra #729
Description
Preflight checklist
- I could not find a solution in the existing issues, docs, nor discussions.
- I agree to follow this project's Code of Conduct.
- I have read and am following this repository's Contribution Guidelines.
- This issue affects my Ory Network project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe your problem
In our iOS/Android application, we have 2 flows where local authentication is used - biometric challenge and device link (similar to passkeys). This local authentication is already producing a JWT with the details of the challenge and user ID.
Both flows use a similar mechanism, though each one has its own token and security considerations. One of the flows is used for Strong Customer Authentication, required by PSD2 regulation
We want to optimize these flows by skipping the web UI of the OIDC flow and performing a headless authentication. RFC7523 already supports this via jwt-bearer grant type. Although in the current version it is not possible to differentiate 2 different tokens and assign each one a specific set of the access token and the id token claims.
Describe your ideal solution
Given that ory/hydra#3254 is done and Hydra has support for hooks in every grant type, we can store the payload of the JWT supplied in the jwt-bearer grant type request and send it to the hook. The logic behind the hook would be able to differentiate between the tokens we have and assign the correct set of claims.
Workarounds or alternatives
It is possible to support these cases with the following:
- Add a JWT produced by local auth as a query param to the
authorizecall to Hydra (open an in-app browser) - Receive the JWT in our custom login endpoint via
getLoginRequest - Validate JWT and assign token claims respective to the JWT supplied
The downside of this is that we would have to open an in-app browser with web UI that would render nothing and would just close automatically. The browser can be replaced by a hidden web view, but it becomes much harder to maintain.
Version
2.x
Additional Context
I'm fine implementing this change in both Fosite and Hydra if it is something you can support. I think it is a great way to integrate iOS/Android-specific authentication strategies without fiddling with the web-based UI.