Support multiple browser clients for a single Kratos instance by using return_to URL of a flow if specified

[reginbald]

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 Network project.
• [X] I have joined the Ory Community Slack.
• [X] I am signed up to the Ory Security Patch Newsletter.

Context and scope

When two separate browser applications use the same Kratos instance we need to be able to specify a return_to url that will redirect users to the browser application that initiated the login/registration/etc flow.

Goals and non-goals

Goals

• URLs in return_to query parameter should be validated against the allow list before being stored with a flow
• Kratos should choose the return_to URL from a flow before falling back to the default URLs specified in the Kratos configuration
• When a registration flow replaces a login flow the return_to url should be migrated to the new flow
  • This happens when a user that does not exist in Kratos as an identity uses a social login

The design

The main goal is to support multiple browser clients hosted on different subdomains to interact with a single Kratos instance. This would be done by redirecting browsers to the return_to URL if specified before falling back to the default UI URLs.

APIs

No response

Data storage

No response

Code and pseudo-code

No response

Degree of constraint

No response

Alternatives considered

• Single Login browser application that would then route users to their final destination
• Running multiple instances of Kratos, one per browser application

[aeneasr]

We already have this? https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion

[reginbald]

You're correct, however what I've found is that this not true in all scenarios (so this should maybe be a bug fix?). As an example when a user that has an email + password entity tries to login with social login (that has not been linked) there will be a NewDuplicateCredentialsError, the user is redirected to the default uri and the return_to query parameter is ignored.

[aeneasr]

Correct, the return_to parameter is only used on success, it can not alter how the system behaves on errors. This is intentional because the user needs feedback on why the registration/login/... failed

[reginbald]

Understood, What I would then really prefer is to have a redirect parameter that would allow browser applications to specify the return url where they would like to handle successful logins or errors. So if we have two applications ui-1.example.com and ui-2.example.com, we would be able to specify a redirect parameter so that the user is returned to the ui that initiated the flow.

[reginbald]

To give a bit more context. I've been using Microsoft identity platform in the past where you have a single active directory for your users and multiple app registrations (one per app) specifying the applications redirect uri and other data. This is doesn't force the developer to run two Kratos instances to support multiple applications. It's seems like this is how Firebase works as well for their authentication mechanism. You configure the authorised domains for the project, users are then redirected to those domains depending on where they are coming from.

So to me if Ory kratos wants to support this there are at least three options we could go.

• Introduce a redirect_to query parameter that would be used if specified (validated against allowed_return_urls) before going to the configured kratos default ui url
  • It would first check (for successfull login) return_to > redirect_to > default ui url
• Introduce an error_to query parameter that would be used if specified in case of an error (return_to could be renamed success_to to make it clear what it is used for)
• kratos configuration would be extended to allow for something similar to app registrations

[reginbald]

I've created a pull request to demonstrate what I mean. Let me know if I'm on the wrong track

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️