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

Recovery flow with Two-Factor does not respect return_to #222

Closed
6 tasks done
Benehiko opened this issue Jan 20, 2023 · 1 comment · Fixed by ory/kratos#3263
Closed
6 tasks done

Recovery flow with Two-Factor does not respect return_to #222

Benehiko opened this issue Jan 20, 2023 · 1 comment · Fixed by ory/kratos#3263
Assignees
Labels
bug Something is not working.

Comments

@Benehiko
Copy link

Preflight checklist

Describe the bug

When creating a recovery flow with the return_to query parameter the url is not respected when the account has two factor authentication with TOTP or WebAuthn since the user is redirected through the login flow asking for the Two Factor credential. After submitting the two factor credential the user continues to the settings page which is correct, however after submitting the settings page the initial return_to query parameter is not respected and the user is never redirected.

Expected Steps:

  1. Get Recovery page with return_to url
  2. Get Email with code
  3. Submit code on Recovery page
  4. Get redirected to settings page
  5. Set a new password
  6. Redirect to the return_to url

Currently the flow ends up being:

  1. Get Recovery page with return_to url
  2. Get Email with code
  3. Submit code on Recovery page
  4. Get redirected to login page for 2FA
  5. Submit 2FA (totp or webauthn)
  6. Redirect to settings page
  7. Set a new password
  8. Stay on settings page

This also seem to relate to ory/kratos#2832

Reproducing the bug

  1. Create a new account with 2FA enabled.
  2. Add totp or webauthn as 2fa
  3. Try recovery flow
  4. Observe the above behaviour

Ensure that the settings flow and sessions flow has the required_aal to highest_available.

selfservice:
  flows:
    settings:
      required_aal: highest_available

session:
  whoami:
    required_aal: highest_available

It also seems that this can be worked around by setting the required_aal to aal1 on both above cases.

Relevant log output

No response

Relevant configuration

No response

Version

latest

On which operating system are you observing this issue?

Ory Network

In which environment are you deploying?

Ory Network

Additional Context

This can be observed by using the Ory Account Experience.

@Benehiko Benehiko added the bug Something is not working. label Jan 20, 2023
@Benehiko Benehiko self-assigned this Apr 28, 2023
@Benehiko
Copy link
Author

The problem happens between the recovery and settings flow specifically since the recovery flow already creates a session with a settings flow.

The return_to is transferred correctly from the recovery to the settings flow, however, the settings flow has a handler which checks for a session. This handler does not respect carrying over return_to URLs from the flow itself or from the URL.

https://github.com/ory/kratos/blob/master/selfservice/flow/settings/handler.go#L103

Here are the steps:

  1. Recovery flow is successful
  2. New Settings flow + AAL1 session
  3. Redirect to Settings UI + flow ID
  4. Get Settings flow is called
  5. Check session active
  6. Requires 2FA
  7. Redirect to Login with AAL2 query param

At step 5 the check does not carry over any return_to query parameters set on the settings flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants