RFC7523: Store the payload of the supplied JWT for later use in token hook in Hydra
sgal opened this issue · comments
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.
Hi @sgal thank you for the feature request. To be honest, I'm not quite sure if I understand what behavioral change you would require for this feature in fosite? Do you want to store the JSON Web Token used as part of the jwt-bearer requires in the database?
Yes, that's what I had in mind. Not the entire JWT though, just a payload would be enough. I'm not sure if DB persistence would be required given that jwt-bearer is a single-step operation. If it can be stored in memory, I would probably prefer that - less changes in the codebase and less ways to break things.
I think that the webhooks have access to the request URL (I might be mistaken though). If that is the case, the JWT would be part of that request URL and could be processed by the webhook target. Would taht be an acceptable solution?
That would be perfect!
Is this the method to use
Line 239 in 7efa846
Yes, that should be it