Recovery self service flow does not pass on redirect_to URL

[zepatrik]

The recovery flow should pass on the return_to or ...recovery.after.default_browser_return_url to the following settings flow. This way the user ends up at the correct page after it completed all steps required for recovery.

Start here:

kratos/selfservice/strategy/link/strategy_recovery.go

Line 456 in 48078e9

http.Redirect(w, r, req.AppendTo(s.c.SelfServiceFlowRecoveryUI()).String(), http.StatusFound)

[Beetix]

Seems like the redirect happens here:

kratos/selfservice/strategy/link/strategy_recovery.go

Line 344 in 48078e9

http.Redirect(w, r, sf.AppendTo(s.c.SelfServiceFlowSettingsUI()).String(), http.StatusFound)

[Beetix]

I took some time to study the code.

When the recovery flow is completed, a new settings flow is created and the user is redirected the settings UI with a flow token:

kratos/selfservice/strategy/link/strategy_recovery.go

Lines 332 to 344 in 48078e9

	sf, err := s.d.SettingsHandler().NewFlow(w, r, sess.Identity, flow.TypeBrowser)
	if err != nil {
	s.d.SelfServiceErrorManager().Forward(r.Context(), w, r, err)
	return
	}
	sf.Messages.Set(text.NewRecoverySuccessful(time.Now().Add(s.c.SelfServiceFlowSettingsPrivilegedSessionMaxAge())))
	if err := s.d.SettingsFlowPersister().UpdateSettingsFlow(r.Context(), sf); err != nil {
	s.d.SelfServiceErrorManager().Forward(r.Context(), w, r, err)
	return
	}
	http.Redirect(w, r, sf.AppendTo(s.c.SelfServiceFlowSettingsUI()).String(), http.StatusFound)

This is sensible since the user is bound to change his password. Unfortunately, this is currently not compatible with the return URL mechanism.

I see 2 options:

• Not creating a settings flow if a return URL is specified
• Calling the return URL with the settings flow token

The later seems more relevant since as mentioned before the user is bound to change his password.

What's your take on this?

[aeneasr]

Thank you for thinking about this @Beetix ! I don't think the second option is valid, it can easily be abused by an attacker to present you a phony "update your password ;) ;)" UI which is actually a phishing site. What we could do though is calling the return_to URL once the settings flow was completed!

[Beetix]

Thank you for thinking about this @Beetix ! I don't think the second option is valid, it can easily be abused by an attacker to present you a phony "update your password ;) ;)" UI which is actually a phishing site. What we could do though is calling the return_to URL once the settings flow was completed!

Yes, calling the return_to URL after the settings flow seems better. I have proposed these ideas while trying to figure out a way to focus the user on changing his password. The issue with the settings flow is that a user can update his profile instead of his password (which is what really matters in a recovery).

[zepatrik]

If you want to prevent that you can omit the other fields in the UI. It will probably change with #929 so that traits and password are separated anyway.

[Beetix]

If you want to prevent that you can omit the other fields in the UI. It will probably change with #929 so that traits and password are separated anyway.

Yes, resolving #929 seems to be the answer to my problem. Having a single URL for both is problematic. If I hide the fields in the UI it means that I'll never be able to change these settings.

[zepatrik]

You can hide them conditionally, e.g. depending on the referrer or some query parameter.

[dan2kx]

Has this been implemented yet? I'm also looking for a solution to get back to a third party app (which uses hydra) after a user requests recovery or when creating a user in kratos and sending out an invite email with the recovery url