What's the best way to prevent different browsers errors?

[sneko]

Hi,

I tried to think a lot about it without knowing/finding the best way to go.

Roughly:

• The user is in a native application on iOS
• He clicks "Login", it opens an in-app browser (Safari)
• He forgot about his password so he clicks "reset password" and receives an email
• To make sure my user goes back to the initial native application I passed the login_challenge within the email link (note: the redirectURI is a deeplink that allows opening native app)
• The user is supposed to click the link, reset, and finalize the login flow back to origin (thanks to the login_challenge)
• ... it works... except if... when clicking the link the user selects another browser (e.g. Chrome)
• He will enter his credentials but then it fails the flow with Hydra. A few months ago (maybe previous Hydra version), Hydra was redirecting the failing user to the global error page while passing as URL parameter error=different_channel, and after upgrading today, it seems it redirects to the original redirectURI will passing an error about a CSRF (which seems logic too). For both I didn't find a good pattern to adopt.

I understand the flow was initiated from a different browser so local storage is not shared and it prevents bad behaviors. But what's the best UX flow so the user can recover from this?

Any help appreciated,

Thanks,

[vinckr]

Sorry for the late answer!
I see the problem, is the in-app browser the users' default browser, or can it be a different one? If it is always the default it should not occur, correct?
Maybe you can do both login & reset in the external browser?
I can't think of anything more concrete now that would solve this, but I will keep my eyes open if I can find something.

[sneko]

Hi @vinckr ,

(wanted to make it short but... sorry 😄 )

No there is no possibility to choose at runtime the browser when in-app. To be clear for "browser in-app":

1. Either your native app has to open a link and can ask the user to open it in one of his browsers (Safari, Chrome...) but that's outside the app, this one is set in background
2. Either you want to open it with an in-app browser so the user when finishing his "web link flow" will end in your app (because this one was just behind the browser, or even more, the browser is partially over the app)

I skip the first case because the experience is less confortable, and you have to make sure the "deeplink" will work for the user to get back into the app (which is not always true after a fresh install). Also it won't solve the problem described above because the browser at this time is maybe not the one when clicking into the email..

For the second case, what you can do is:

• Open in-app the native "light" browser (on iOS it will open Safari, on Android it will open "Android Browser" (maybe it's Chrome now... just remembering this specific browser)
• Or you want to use a custom browser for specific reason (customization...) but your app has to embed it (which mean your own app will be more weight...)

The best for us is to choose the native one (Safari for iOS, "Android Browser" for Android) because you may share some state between the browser app and your in-app browser. That's why I have no issue and it will work if I do my entire flow with Safari on iOS.

But when the user has another default browser (not the device default one), let's say, "Firefox": opening the link from the email will open Firefox and after logging in, Hydra won't find cookies needed to authenticate this browser and it will fail as described in the issue.

To think more generic, instead of thinking with browsers on the same device, just think about me starting the "forgot password" flow from my mobile app, but clicking the email link from my computer... Hydra won't recognise me as the originator of the flow.

I definitely see no easy way to improve the UX so the user avoids an error... and since I don't find information about that I may think I'm doing something wrong? Thoughts?

Thank you,

EDIT: note this is not a fatal dead-end, because the user will get back to the client app, with an error from Hydra, and the user just has to click "log in" again, to get onto my Identity Provider UI, enter credentials... and then he will be logged in. That's just when the user cuts his flow with an email that things start to go wrong, while keeping in mind that he can catch up by redoing the login flow after (considering no email since he should have solved his forgotten password for the second attempt...)

[sneko]

@vinckr , what I did this week to mitigate this is to try isolating before the email and after.

I know I showed you the "forgot password" example but that's the same if the user tries to register (even if he initiated a login flow), an email flow is required for both.

Let's the say the user open the in-app browser to log in, he has no account so he clicks on "register" (still in-app browser), fills his information... and once done I show him this:

Like that he knows he has to confirm through the email and come back here. If he clicks "I've confirmed", I can show the hidden login form. Which means, same browser... Hydra will let him pass! 🥳

... but before clicking the button, the user will (normally) open his email, click the link, and no matter in which browser he will open it, I make the registration confirmation kind of dead-end page to make sure the user will resume his flow in the initial tab (or initial browser, on initial device).

This is kind of experimental on my side... just trying to work around things 😀

What do you think about that? I may adapt this for all email flows (registration, forgotten password, update password...).

[vinckr]

This looks like a neat solution from my end, that is way less frustrating than encountering an error and is still using all the flows correctly as far as I can tell. Are you using Ory Kratos for the self-service flows?

I think a small improvement on the first screen would be to write:

"We sent you an email so you can confirm your account and start using it!
When done, come back to this page and access your account below"

But your version works nicely too !

[sneko]

No I don't use Ory Kratos, it was quite new (really really new I think remembering) at the time I chose Hydra so the rest is homemade 😄

Good if you validate the solution 👍 . If you hear about something more obvious, please keep me updated.

Thank you,

[aeneasr]

Hello @sneko . In OAuth2, it is not possible to switch browsers mid-request due to security reasons. The best option you have is to make the registration flow independent of the OAuth2 flow. So the user signs up, and once signed up, you re-initialize the OAuth2 flow.

Another option is to initiate the OAuth2 flow, then register the user, validate the link (regardless of browser), and ask the user to go back to the original tab where the OAuth2 flow was initiated. There you do some checking if the user is now registered, and continue the flow.

[vinckr]

quoting #2652 (reply in thread)

Hello @sneko . In OAuth2, it is not possible to switch browsers mid-request due to security reasons. The best option you have is to make the registration flow independent of the OAuth2 flow. So the user signs up, and once signed up, you re-initialize the OAuth2 flow.

Another option is to initiate the OAuth2 flow, then register the user, validate the link (regardless of browser), and ask the user to go back to the original tab where the OAuth2 flow was initiated. There you do some checking if the user is now registered, and continue the flow.