You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Configure an identity schema with a phone verifiable phone number
Configure Kratos to enable SMS based 2FA
Configure Kratos to use highest_available on whoami, settings, or other self service flows
Log into Kratos
In a settings flow, add a phone number to the account, complete the verification process
In a settings flow, add TOTP to the account
Log out
Attempt to log in with email/password
At this point, Kratos will redirect the client:
{
"error": {
"id": "browser_location_change_required",
"code": 422,
"status": "Unprocessable Entity",
"reason": "In order to complete this flow please redirect the browser to: http://127.0.0.1:4433/self-service/login/browser?aal=aal2",
"message": "browser location change required"
},
"redirect_browser_to": "http://127.0.0.1:4433/self-service/login/browser?aal=aal2"
}
However, navigating to the URL provided will result in an error screen, with the following error:
{
"id": "ff1cb352-2137-40e9-8eb5-04f4c74ffdd1",
"error": {
"code": 400,
"reason": "AAL2 login via code requires the `via` query parameter",
"status": "Bad Request",
"message": "The request was malformed or contained invalid parameters"
},
"created_at": "2024-03-07T01:53:18.011166Z",
"updated_at": "2024-03-07T01:53:18.011166Z"
}
Note: I've focused on the login redirect here, but equivalent broken redirects are generated when making other calls, such as to whoami.
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.
The text was updated successfully, but these errors were encountered:
MichaelMarner
changed the title
Kratos redirects incorrectly to AAL2 login flows if identity has SMS and another 2FA method
Kratos redirects incorrectly to AAL2 login flows if identity has both SMS and another 2FA method
Mar 7, 2024
MichaelMarner
changed the title
Kratos redirects incorrectly to AAL2 login flows if identity has both SMS and another 2FA method
Kratos generates broken redirects to AAL2 login flows if identity has both SMS and another 2FA method
Mar 7, 2024
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.
The text was updated successfully, but these errors were encountered: