Background
We are in the process of migrating our existing Auth rails stack to Auth0 using omniauth-auth0. Our existing stack allows anyone to login with a password, OTP via email, or google. Our existing stack allows any user to switch freely between the options. Most people stick to one option, but any option is valid.
Account linking
Because we want all three connections to refer to the same user, we have set up account linking so these three identities are one.
The problem
If we want to support passwordless users, we have to specify that as the connection parameter. But if a user wants to change their mind and sign in differently, things get clunky.
What we tried
We added a button to one of the partials in our universal login template. This button called back to our application which would then send the user through the flow using “email” as the connection (yes, we’re aware of the risk of vulnerability here) and passing any email entered as the login_hint.
That works well… except when we send the user to the login screen with the “email” connection, our button to switch to email is still there.
And if the user doesn’t enter an email, we don’t have a login hint so we’re back to the same screen. If we use a “space” for the login hint, we’re sent to the code entry screen but clicking “edit” for the obviously wrong email sends you back to the same place as well. And there’s no option to switch to password.
What would solve all of our problems
Being able to detect which connection was in use would allow us to hide/show buttons on the form conditionally.
In a perfect world
This would be built into Auth0 itself to avoid bouncing between different systems. Our current implementation just adds/removes fields based on the user’s actions.
What we’re also considering
We could have the buttons to “choose your own adventure” starting from our application.
That gets a little clunky with google auth since they have to click a button to get to an Auth0 page to click another button if we want to stop supporting it locally/enable SSO functionality.
This turned out to not be true. Specifying just google-oauth2 had a streamlined experience.