Customer wanted for users to have 4 login options.
Email password
Username password
Email passwordless
SMS passwordless
I enabled both Database and Passwordless connections. After signup (where user was created in Database connection with email and username) in post-login action I’m creating user in Passwordless connection with email and another one with phone (collected in Auth0 form), then merge all three users into one and this way I have user that can log in with all 4 requested methods.
PROBLEM: switch between password and passwordless login screens.
When using passwordless we have to use Identifier first authentication profile. Login method is set up in connection query parameter to /authorize endpoint. /authorize?connection=email - login passwordless with email /authorize?connection=sms - login passwordless with sms /authorize - login with password
Then we end up in /u/login/identifier?state=. If, for example, we modify this url to /u/signup/identifier?state= (no changes to state query parameter) user will be able to signup - easy-peasy. But there is nothing similar for redirecting to passwordless login screens. I’m not quite sure where Auth0 stores information of what screen to display (probably on the server and uses state or part of it as a key).
I made it work with double redirection. Email Me a Code button redirects to customer’s site with additional parameter e.g. https://site.com/auth0_redirect=1&connection=email, I handle this parameter, generate & store new state and nonce and redirect to /authorize?connection=emal. Same with sms. And text on buttons is hardcoded in a template for each login screen.
But now Auth0 is used as SSO on the platform customer moved to. Login with password works as expected. But on that platform I only have button that redirects to the login screen, I can’t specify parameters. Also from login screen I can redirect back to platform, but there I can’t handle query parameters in any way.
QUESTIONS:
Are there ways to switch password and passwordless login screens (other then what I described).
Where does Auth0 put that connection parameter when redirects to /u/login/identifier?state=? If I have more understanding maybe I will find other ways.
Can ACUL help me with that switching between login screens?
How is the Auth0 SSO setup exactly on the new platform? Does Auth0 act as the main IdP or as an external one?
Are there ways to switch password and passwordless login screens (other then what I described).
There isn’t a straight forward or out of the box solution regarding such an approach, by default, Universal Login will not be able to work with both Database and Passwordless connections unless they are specified as a parameter in the /authorize call. Your approach appears to be quite a sane one and a pretty good workaround for including all of these alternatives inside universal login.
Where does Auth0 put that connection parameter when redirects to /u/login/identifier?state=? If I have more understanding maybe I will find other ways.
Unfortunately, you will be unable to pass in a parameter when reaching the /u/login endpoint. In your situation, the best solution regarding having this resolved would be to have the SSO button redirect to each specific connection type by having different /authorize calls linked to them. As you have mentioned, if you do not have control over the platform, this is hard to achieve indirectly.
Can ACUL help me with that switching between login screens?
The best approach regarding your implementation would indeed to be using ACUL. Basically:
The external platform would redirect to your /authorize endpoint without needing to specify the connection parameter.
Using ACUL, you will render a simple screen asking to either Enter Email Address Or Username or Choose Another Method
If the user chooses to continue with the email or username, continue with the standard identifier first flow
If the user chooses another method, use a custom JS script in order to redirect to a new /authorize call passing in the specific connection parameter
In my opinion, this approach would be the best one since it allows you to meet the requirements which where restricted by the SSO flow.
If I can help with anything else, please let me know!