Redirect loop for recovery combined with 2fa

[ariep]

Hi, we've been using Kratos (and Hydra) for quite some time in our project, thanks a lot for it!

Recently we've been implementing 2FA, but now I've hit a redirect loop. I can reproduce it -- with my own app -- as follows:

• Start from an empty slate, no session.
• Start to log in, enter email&password.
• In the screen that you get to enter your TOTP code, click the link we include on every login page ("Set new password") to the entrypoint for account recovery.

What happens then:

1. Our own recovery entrypoint page redirects to /kratos/self-service/recovery/browser.
2. Kratos redirects to the configured generic login page.
3. Our login page backend checks for an existing kratos cookie, finds one, calls the public frontend api endpoint to_session to lookup the session based on the cookie.
4. Kratos returns an error to to_session, saying that the aal is not high enough and suggesting we redirect to /kratos/self-service/login/browser?aal=aal2.
5. We ignore that suggestion (see below [*]), and start a new kratos login flow by redirecting to /kratos/self-service/login/browser.
6. Kratos redirects back to our login page, but it doesn't include a flow= parameter for some reason.
7. Our login page, as it doesn't get a flow parameter, is in the same situation as in 5. and the loop is complete. We get redirected back and forth between kratos and our login page.

[*] To explain why we don't follow kratos' suggestion of redirecting: note that this is the app's login page. We arrive at the same code path if you do a regular login, first entering email&password, and then your 2FA. If we do pass on the redirect suggested by kratos -- I tried that -- you'll get in a redirect loop in this regular login process. I don't yet see something that would allow us to make the distinction at that point in the code between the recovery context and regular login -- it's just the login page, which doesn't know about the recovery that prompted it.

So my question is: how to fix this :). More specifically and maybe more helpfully:
A. At step 1. above, is it expected that when starting the recovery flow, Kratos redirects to the login page? I guess that's because we require 2FA for recovery (by setting kratos.config.selfservice.flows.settings.aal_required: highest_available), but somehow I did not see that coming. I guess I had expected the 2FA to be part of the recovery flow, instead of a whole login flow as I seem to get now.
B. Is it reasonable to ignore the redirect suggested by Kratos at 5.? If not, how should I prevent the redirect loop for the regular login mentioned in [*]?
C. Why would Kratos not include the flow parameter at 6.? I'm not even sure if the recovery would complete successfully if it did, but the failure to include the flow seems the immediate cause for the redirect loop.

Sorry for the long text, thanks for any advice!

[vinckr]

Hey @ariep

Some tips that might help:

A. The account recovery flow in Kratos involves sending a link or a one-time code to the recovery address defined by the user. The user must access the link or enter the code they received to confirm their identity and ownership of the account. When the user accesses the configured recovery method, they receive a privileged session and are taken to their account's settings page where they must create a new password to regain access to their account. The account recovery flow doesn't reset user's second authentication factor. source
B. In the case of redirect loops after successful registration, Ory redirects users back to the registration page after a successful OIDC flow when some identity traits, for example a phone number, couldn't be mapped using the data received from the social sign-in provider and require manual input from the user. However, when the Jsonnet configuration for the social sign-in provider is incorrect and Ory can't map the data correctly, the user sees no input fields and the registration page gets stuck in a redirect loop. To fix the redirect loop, adjust the Jsonnet configuration for the social sign-in provider so that the data from the provider gets mapped correctly to the Identity Schema. source
C. I don't know...

[ariep]

Hi, thanks for your reply.

A. Right, I don't have problems with the recovery flow per se: it works fine for us usually, except when I start it from this particular state halfway through login.
B. We don't have user-facing registration at all, new users are created by admins through the api. The redirect loop mentioned in [*] happens during login.

[ariep]

This is still biting us. Any ideas?

[vinckr]

Hmm, its been a while but to make sure:
This is a redirect loop that happens only when the user selects "forgot password" on the 2FA screen - after they already entered the correct password?

[jbstoverPraxent]

Very interested if anyone found a fix for this. Running into a very similar problem only with users accessing a fresh login page and immediately hitting step 5-7 of OP's description.

[ariep]

Yes for us it only happens when someone starts a recovery when they've already entered their username/password but not yet their 2FA. I've mitigated the problem by removing the recovery link from our 2FA input page, but users can still be unlucky enough to hit the recovery button at the wrong moment, for example in another tab, browser history, etc.

I don't have a proper fix at this time.