Sign in with security key not working if email is cached

[lukasSerelis]

What is happening
If you try to sign in but don't complete MFA and visit the initial sign in page again, it caches the email and only shows password and security key sign up options, even if security key is not set up. If the security key is not set up it's not putting an error message, it just keep redirecting back to the same page.

What should happen
First of all it shouldn't obscure the email address that is cached, it's bad UX practice as the user might be trying to sign in to a different account, and you're making them guess which email has been cached. Display the email even thought it's been cached. Secondly, either display all methods of sign in or only supported ones, cause now you're doing neither.

Preferred flow

Flow in screens

1. User visits resource that is accessible via Login UI. UI displays all of possible sign in methods
   

2. User signs in with email and password. Login UI asks for MFA. User closes the tab
   

3. User visits resource that is accessible via Login UI. UI displays cached email with ability to edit email, and all sign in methods that this email is able to use (in this example, email has security key and google, but not Okta set up for this identity.)
   

Compromise option
Same flow, but display all of the possible sign in option, regardless of what options are possible.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/IAM-1114.

This message was autogenerated

[nsklikas]

I don't really like the approach we take here:

• the button that says Change e-mail, seems weird/counter-intuitive to me as a user.
• The logic for resetting aal1 feels very hacky and I think will be difficult for someone who does not have our context to extend.
• Even though we ask the user to provide their password, this is not needed. The session is cached in the cookies (we can just redirect them to the 2fa page.

We should have a look at what major providers do and copy them. For example on github (not the best example, I know) if you press back on the authorizer screen, you will be asked to enter your username/password again and if you do browser forward, you will again will be asked for totp.

I think for us the best flow would one of the following:

• show the user a message that says something along the lines Please validate that this is you: {email} and underneath 2 buttons (one for accepting and one for declining). If they decline, then we delete the user session and we show the login screen as well. If they accept, then we set the aal param to aal=aal2 in the query param. This will show the user the totp page again.
• Do something similar to github and automatically reset the session and clear both fields, this would need some more work as we would want to keep the forward button working as well.

What do you think? cc @lukasSerelis @edlerd

Originally posted by @nsklikas in #292 (review)