Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consent Screen page #345

Open
3 of 5 tasks
jonas-jonas opened this issue Jan 29, 2025 · 3 comments
Open
3 of 5 tasks

Consent Screen page #345

jonas-jonas opened this issue Jan 29, 2025 · 3 comments
Assignees

Comments

@jonas-jonas
Copy link
Member

Preflight checklist

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:
    Image

@ory/nextjs:

Workarounds or alternatives

Version

master

Additional Context

No response

@jonas-jonas
Copy link
Member Author

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:

  1. Re-write the components to remove the underlying assumption that there are UI nodes.
  2. 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.
  3. Copy & Paste/reimplement the UI Nodes for the consent screen
  4. 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.

@aeneasr
Copy link
Member

aeneasr commented Feb 24, 2025

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.

@aeneasr
Copy link
Member

aeneasr commented Feb 24, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants