Open MichaelMarner opened 5 months ago
It feels like the via= request parameter isn't really the right approach to start an AAL2 login flow
I tend to agree, however, the reason the behind it was, that there could be multiple traits setup for MFA and choosing the correct one for the particular flow, would then be impossible.
One improvement for this could be to add this information to the identity schema, and then check if there are more than one trait that could be used to complete the MFA flow. And then only require via
if there are more than one.
Since we can't know which trait the implementor wants to use to fulfil the MFA flow, we can't generate the via
parameter into the URL from the browser_location_change_required
error either. And while this leaves this edge case in a broken "state", there isn't really a great solution to the problem.
Showing a second screen to let the user choose which method they want to use is a great idea, and we're currently experimenting with these multi-step flows in the "regular" login flow. Implementing this for MFA shouldn't be that difficult, as we already have most of the data at hand at that point (the identity + identity schema).
Preflight checklist
Ory Network Project
No response
Describe the bug
If an identity is configured for SMS 2FA, and also has another 2FA method configured, such as TOTP, then any redirects to an AAL2 login flow generated by Kratos are broken, as they do not include a
via
request parameter.Reproducing the bug
highest_available
on whoami, settings, or other self service flowsAt this point, Kratos will redirect the client:
However, navigating to the URL provided will result in an error screen, with the following error:
Note: I've focused on the login redirect here, but equivalent broken redirects are generated when making other calls, such as to whoami.
Relevant log output
No response
Relevant configuration
Version
1.1.0
On which operating system are you observing this issue?
macOS
In which environment are you deploying?
Docker
Additional Context
It feels like the
via=
request parameter isn't really the right approach to start an AAL2 login flow - it requires the client to know too much about how Kratos is configured, and requires the client to have information about the identity that is not possible to know (ie what 2FA approaches are enabled on the account). It makes the client very brittle and at risk of breaking if any Kratos configuration changes.I think Kratos needs another step to the login flow that generates a UI presenting all the ways the user can complete AAL2 authentication, allowing the user to select "use Authenticator app" or "send an SMS". Kratos could be configured to have a default or preferred option.
This matches what other services tend to do. For example Github I have TOTP and phone number configured. When I login, Github asked for my TOTP code by default, but also gives me the option to authenticate with an SMS or recovery code.