Replies: 1 comment
-
Hello @jothomps This is the core issue, right?
Ory Kratos supports two types of flows: browser flows and API flows. The browser flow redirects the client and uses cookies to protect against CSRF and session hijacking attacks, while the API flow responds with a fresh flow formatted as application/json right away. The client then uses this information to render the UI. In the case of an error during the Self Service User Login, Ory Kratos will store the error message and context and redirect the User's Browser to the Error UI URL set by the selfservice.flows.error.ui_url configuration or SELFSERVICE_FLOWS_ERROR_UI_URL environment variable. For advanced URL redirects, the application can pass a ?return_to= query parameter to the endpoint that initializes a flow. The return_to URL is the redirect URL after the flow is completed. However, the return_to query parameter doesn't automatically persist across different flows and must be added to new flows. It seems that you might need to manage the return_to parameter carefully to ensure that the user is redirected correctly in case of an error. However, I am not sure what a direct solution to your specific problem would be. |
Beta Was this translation helpful? Give feedback.
-
Hey there,
I'm currently working on an app in Flutter that makes use of Kratos for account management. Our initial implementation of login used an InAppWebView to handle the process via the browser flow, but we've since decided to move login back into native Flutter UI, meaning we've switched to the API flow.
For the most part the flows are completed, including the SSO flow using ASWebAuthenticationSession on iOS and Chrome Custom Tabs on Android. If there are no problems, the flows work great, but we are stuck on what happens if there is an identifier conflict during the SSO. For instance signing in with Google, but the account already exists via either Apple sign in or email/pw.
The problem we're facing is that the SSO browser gets redirected to our browser login ui_url, but due to the flow being initiated as API and not browser, email/pw login as well as account recovery no longer work. If we modify the login ui_url to point back at our app the redirect works, but unfortunately it completely breaks any pre-existing login setup we had for our browser flow.
So the question I'm asking is, is there a way to have the failed SSO redirect go back to our app ONLY in cases where the flow was initiated via the /api endpoint, while still preserving our online flow?
Any responses and help greatly appreciated. Thanks!
Beta Was this translation helpful? Give feedback.
All reactions