There is no way to tell the difference between a user who signed in and a user who is in the recovery mode

[radekg]

Is your feature request related to a problem? Please describe.

Initializing a recovery process sends an email with the recovery to the user. The user clicks the link and is taken to the application selfservice.settings.ui_url. Now the following has happened:

• the settings flow from the recovery process initially has the request_url value of the Kratos /self-service/recovery process
• at the same time, a session is created for the user and the user can reach the /sessions/whoami and retrieve all data
• the settings flow from the recovery process is totally indistinguishable from the regular settings flow, it not only allows resetting the password but ALSO updating the profile info without updating the password, WITH the email address
  • in that sense, this isn't really an account recovery but a fully fledged session
• a user with the recovery session can further request new settings flow, if the recovery issued settings flow expires

Is this behavior desired?

Describe the solution you'd like

I'd expect that the recovery session is a temporary session without profile info and allowing only password reset and not a full profile edit. I'd expect this session not to be able to request a new settings flow, as in, if it expired, the user should have to reinit only via recovery.

Currently there is really no way to tell the difference between a user who signed in and a user who is in the recovery mode.

Maybe there should be some sort of recovery flag on the session object?

Describe alternatives you've considered

If there was the recovery type of a flag on the session object, it would be possible to limit the scope of changes the user is allowed to do.

Additional context

N/A

[radekg]

Something definitely isn't right here. I initialize the recovery from the browser and I am logged out, no session cookies set in the browser. I receive the email with the flow and token. I click on the link from the email and am taken to the selfservice.flows.settings.ui_url with an unrelated ID of the flow to the one from the email. I can then fetch the settings flow via /self-service/settings/flows but not /self-service/recovery/flows (http 404). My flow comes back as settings and you can see this here:

When I have no cookies, as in, via cURL, I get the redirect to the selfservice.flows.recovery.ui_url. With cookies, in the browser I am being sent to selfservice.flows.settings.ui_url with an unrelated settings flow and I get the session object, too (cookies set).

So far, so good. According to the documentation at https://www.ory.sh/kratos/docs/self-service/flows/account-recovery#recovery-for-browser-clients, this is the expected behavior.

This brings me to the conclusion that my original thinking was correct and the question stands:

is there a method to distinguish between a user who is signed in and a user who is in recovery mode?

[radekg]

Hi @aeneasr, would a simple flag like that work for you? If yes, then all the blocking of actions that should not be allowed to a recovery user could be implemented. Eventually, what a desired implementation could look like?

[radekg]

The #1323 PR introduces the recovery session. With that flag, it's really easy to distinguish between the intent to recover and a signed in user. The video shows the concept.

kratos-recovery-session.mp4

[aeneasr]

Account recovery is essentially a privileged session which allows one to update their credentials, thus it is analogous to setting a session.

Resetting a password is not all that you can do here, it might also be to recover a broken link to an OIDC provider. Thus, the flow is more complex than showing a mask for changing the password!

However, adding a flag to indicate a recovery session is definitely a good idea!

[aeneasr]

Once #1624 is merged you will get a list of authentication methods in the session where link_recovery is referring to a session issued as part of the recovery!