-
-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Username / password authentication megathread #2023
Comments
I'm going to try a spike of integrating passport.js into our authentication code and hopefully will implement this along the way. Potential advantages of passport.js:
Similarly, I may find other libraries that would beneficial for these reasons. |
@louh correct me if I'm wrong, but I believe if we make this an option, we need to add a sign up page.
https://auth0.com/docs/users/user-account-linking Account linking is not allowed in the free plan. However, it might still be worth implementing anyways. We might have 'duplicate' accounts, but not sure if that is effecting our target users who are behind firewalls, since the whole problem is they don't have an account in the first place. |
its old but I saw some inspiration here: |
I had opened a couple of threads over on the Auth0 support forums to try and gather more information about the issues we're running into. Linking here for additional context. (cc @reefdog, welcome to this issue!) The response from their support team:
The helpful bit is the reference to the "email client", and the users I've talked to all use Microsoft Outlook. So far that may be a common culprit. Unfortunately, they were not helpful about next steps, and we certainly have no control over how organizations implement and deploy their email clients. I followed up with a post asking about how to migrate from passwordless to another option. Hopefully this is useful! |
Excellent! Yes, for the record my two opening questions were:
I'm first gonna do some additional due diligence on solving this without totally reworking our auth stack, so we can treat the latter as its own weighted task. Failing that, I'll move on to exploring adding the username/password auth. (I'm assuming, until we run into Big Reasons otherwise, we're sticking with Auth0 as the auth stack, and so will look first at their Universal Login.) |
Surfaced from one of those support threads and the Auth0 config: have we already explored/discarded using the emailed code instead of a magic link? Our current theory is that something about corporate email systems (or clients) is pre-loading/expiring the magic link; the code wouldn't have that problem. It's a less-than-ideal UX since it requires more user interaction than just a click, and is less familiar than a traditional username/password login. But it would require very little config change on the Auth0 side, no change to our login infrastructure, and just (well… "just") a new screen and handler on the Streetmix side. Seems like a pretty good cost-benefit, though ROI may still be lower than just converting to Universal Login. |
Thanks for the overview, and I agree with this assessment. I have no problem making the simpler change and adopting magic codes, although I personally don't like the UX of it either. If converting to Universal Login doesn't seem too too time-consuming (including the process to transition users into setting passwords), then a little more effort for higher ROI does seem like the right move. |
After mulling it over a bit, reading up, and talking to @easherma, I'm no longer convinced the ROI on doing codes is worthwhile. It's fine and would "solve" the immediate problem, but I think we all agree it's a crummier UX than both magic links and traditional U/P. I surfaced another recent Auth0 community thread with this issue, and it's getting a little more traction: “Link protect” software breaks passwordless auth. Hoping a solution comes out of that. Theoretically, server-side URL sanitizing/checking would cause this problem, but it's almost quite likely to just be Outlook's Link Preview, which seems like a fantastically poorly-considered feature. Shortest-term, if/when people write in with this issue, we can recommend they disable Link Preview long enough to receive the email and log in, and then re-enable Link Preview if they want. Not at all the permanent solution, but will at least let them authenticate with their preferred email address. |
This commit adds a button to the sign-in dialog for using the Auth0 Universal Login page, enabling username/password-based authentication. The button is currently only rendered in non-production environments, though that guard would be removed before merging the PR. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
Okay, so! With #2329 (essentially rewritten from #2035), we've got a proof of concept of linking our sign-in dialog to the Auth0 Universal Login screen. Right now we're serving up the Classic Experience login screen, but as soon as we resolve the issue with our social provider dev keys, we can flip on the superior New Experience. (Nicer interface, faster-loading, better i18n.) For the R&D I just added a button to the bottom of the social providers; clicking it goes to the universal login screen: However, we can do a little better. We can keep our existing sign-in dialog, but when a user enters their email address and clicks "Continue with email", we then go to the universal login screen, with the email pre-filled. If we go this route, we'll want to add explanatory text until users are fully on-boarded and comfortable with this change in authentication strategy: One slight weirdness to this approach: the social connection logins will be present on the Universal Login screen, too, which feels a little weird. Ideally we'd just offer them here (on the dialog), and then if the user took the email path, they only see email-related functionality. But, I think that's acceptable. For reference, here's the Universal Login screen itself, in Login mode: Also! We can hint that we want it to prefer Sign Up mode |
More interface notes on the above:
More infra notes on the above:
|
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
After some more hashing out, we settled on something way cooler: providing Password login as an additional option without yet removing Magic Link! Users who want to keep using magic links can do so, but now we've got the password option for those who can't use magic links. To gently push everyone toward passworded accounts, we've made this the default form submit behavior. Users without a password who end up on the Universal Login flow can just click the Sign Up button on that screen, but we've also got the "sign up here" link in the help text that goes directly to that mode. (Both the login and sign up modes will prefill with whatever email the user entered, if any, but only the form-submit/login version actually performs validation.) #2329 has been updated accordingly. |
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
Blargh. We can't do this after all. Turns out that the New Universal Login experience… doesn't support Passwordless logins. (How did it pass my testing above? I think I was unintentionally triggering the classic experience under certain conditions. 🤦🏼) So, our options:
|
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
I wrote this in Discord, should've written it here, copying over for posterity:
|
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
So, as @louh surmised, removing the That means we need to build a guard into our auth process that recognizes if the email is unverified and prevents authentication until the user verifies their email. I've got most of the hooks for this written, and will commit it when I'm finished with some testing. |
This wasn't actually affecting us, but it was causing developer (me) confusion: we declare the `user` const in this block, and then again in a lower scope (the API callback). To alleviate that confusion, I renamed the constant at this scope. Done during but not directly related to #2023.
Adds an error page for when users attempt to login with an unverified email, along with a couple of TODOs for completing the work. Affects #2023
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
This wasn't actually affecting us, but it was causing developer (me) confusion: we declare the `user` const in this block, and then again in a lower scope (the API callback). To alleviate that confusion, I renamed the constant at this scope. Done during but not directly related to #2023.
Adds an error page for when users attempt to login with an unverified email, along with a couple of TODOs for completing the work. Affects #2023
This commit adds support for logging in via password using the Auth0 Universal Login screen. It keeps around the existing magic link support, but relegates it to a secondary (well, stylistically tertiary) button. Native form submit of the email field now goes to the password login. To ease users into it, we added explanatory text advertising the feature and also directing them to the sign up page, although they can also sign up from the login page itself. It also replaces a few `this.state` direct-usages with destructured assignments as a small bit of inline cleanup. Co-authored-by: Whitman Schorn <whitman.schorn@gmail.com>
It turns out that the new Universal Login experience at Auth0 doesn’t yet support passwordless login, something I unfortunately didn’t catch during 336f4b7. Given the choice between abandoning new Universal Login or migrating all email users to passworded accounts, we prefer the latter. This change comments-out (with DEPRECATED notes) the magic link code and changes the sign in dialog language. We will eventually remove the deprecated code once we’re sure of the permanency of this decision.
This wasn't actually affecting us, but it was causing developer (me) confusion: we declare the `user` const in this block, and then again in a lower scope (the API callback). To alleviate that confusion, I renamed the constant at this scope. Done during but not directly related to #2023.
Adds an error page for when users attempt to login with an unverified email, along with a couple of TODOs for completing the work. Affects #2023
Latest update. 😮💨How does an email address get verified?
What accounts do we want to merge?
We will not merge accounts where the unverified email address is newer than the verified, or of course when none are verified (though this latter case has no user story I can think of). What can people with unverified emails do in Streetmix?
How does this translate to actual tasks?Over in #2329, I'm blocking people with unverified emails from fully authenticating, instead telling them to go verify their emails. Still to do:
|
Overview
A significant amount of professional users on corporate / firewalled systems are unable to use passwordless e-mail login because those systems will attempt to sanitize login links, or pre-check them, which nullifies their login attempt. These users are also less likely to use social media accounts for login, because they prefer to link their Streetmix usage with their professional identity. They would also then be less likely to use personal e-mail accounts, as well, or are unaware that this can be solution to their login problems.
One way to work around this issue is to implement password-based authentication to Streetmix. We intentionally avoided this in the past in order to limit our exposure to risk, re: stolen passwords. However, with Auth0 as intermediary, we should be able to achieve this without storing passwords on our own servers.
Questions
A rough to-do list [WIP]
The text was updated successfully, but these errors were encountered: