ory
Consent Screen page
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.
- [ ] I have joined the Ory Community Slack.
- [ ] I am signed up to the Ory Security Patch Newsletter.
Ory Network Project
No response
Describe your problem
@ory/elements-react does not implement the consent screen yet.
Describe your ideal solution
It should implement a consent screen, following what is implemented in https://github.com/ory/elements/blob/main/src/react-components/ory/user-consent-card.tsx, and https://github.com/ory/kratos-selfservice-ui-node/blob/master/src/routes/consent.ts.
@ory/elements-react:
- a basic UI screen:
@ory/nextjs:
- helpers to handle skipping consent
- https://github.com/ory/kratos-selfservice-ui-node/blob/master/src/routes/consent.ts
Workarounds or alternatives
Version
master
Additional Context
No response
This seems more complicated than anticipated.
The problem is, that the "Consent flow" works fundamentally different from the self-service Kratos flows. The main issue is, that the consent flow does not have UI nodes, but the consent UI does not have them. Most of the re-usable components were built with the UI nodes in mind, so just "re-using" them for the consent flow is not possible as is.
Possible solutions:
- Re-write the components to remove the underlying assumption that there are UI nodes.
- Extract the styling for the necessary components to "styled components" that just render the information given to them and remove the need for UI nodes like that.
- Copy & Paste/reimplement the UI Nodes for the consent screen
- Implement a UI nodes based API endpoint for the consent screen
Out of these options, 2. & 4. would provide the cleanest API for consumers implementing their own UI. However, it's still a complicated implementation path.
Another question is how many people would actually use a generic consent screen. Most OAuth2 consent screens I've seen are quite customized, providing more specific information to the user or not letting them choose scopes, etc.
4 is the best option, but I think we could/should implement a translation layer in Ory Elements that translates the consent and login and logout object from Ory Hydra to the UI nodes. In my view that should be quite straightforward.
Another question is how many people would actually use a generic consent screen. Most OAuth2 consent screens I've seen are quite customized, providing more specific information to the user or not letting them choose scopes, etc.
Most customers moving off of Auth0 and using OAuth2+Identities use the default implementation, so it definitely is important we use it.
That also would allow us to - in the future - inject things such as scope translations or descriptions, and other things that are not directly implemented in Ory Hydra and UI specific.
I think it's also great to have examples of good/expected UX patterns to follow before users go off and create their own components from scratch.
Hey @ChazUK
would you be willing to create an issue in ory/docs and describe some of the examples that you would like to see here?
That would help us a lot to plan our work there.
