@zmiro Thanks, Julien! Would love to hear your feedback once you've signed up and implemented the code. Please join our Discord if you need help or have further questions. π
This is awesome, and I personally have gotten more insight into how the product works from @nevilbutani
This is a great way to access your accounts without remembering any passwords. Congrats on the launch! π
Hi everyone!
Today, weβre releasing the most powerful passwordless solution ever built! π
What is passwordless?
Users can enter their email ID or phone numbers and receive a "Magic Link or an "OTP" instead of a password
Magic links are URLs that contain a unique identifier (password) embedded in the URL itself. The OTPs and magic links are time based, one time use only. They expire quickly and can only be accessed by someone who has access to that specific email ID or phone number.
Advantages and concerns:
Users often reuse the same password or use "password123" which can be guessed or brute forced. Removing passwords out of equation removes this concern
In terms of UX, passwordless may present a significantly improved UX depending on the type of app and user
For eg: Phone number based OTPs may be a great way to maximize sign conversions for mobile apps.
We support email and phone based auth in our implementation of passwordless. WebAuthN and push notif based auth coming soon!
I'd love to hear what you think about passwordless and answer any questions about user experience and security!
Why I like Passwordless? It reminds me of my conversations with Dad.
I keep asking him to create secure passwords and manage them as I say. And he keeps complaining it is hard to remember passwords and keeps asking me the same questions repeatedly
* why can't I create a simple password as "password123", I have nothing to hide
* why can't I reuse it everywhere, what would someone get by hacking my account
* ok, I will create different strong passwords everywhere. Can I write it in a diary then?
and a very deadly question - why can't I share my password with my friend. He says that all his friends do all those things and they have never been hacked.
When I think more closely, that's the level of awareness or tech experience of most people. Dealing with passwords gives them a headache. It seems like a common sense to us developers who are well aware of what happens in the background when we make a login request. When we give those people password-based auth, we expect them to work as per best practices while in reality, they make the worst choices and this makes the password-based auth highly insecure.
I think passwordless fills this gap, makes systems more secure for users who are not that tech savvy. Definitely, passwordless auth goes on top of my list of auth strategies to implement in my next app.
I'm curious what are some guidelines that we can give to end users(similar to my Dad) to make passwordless more secure and easier to use? Althoug most of the passwordless security I see is at the implementer side only but still if there are any thoughts from the community, I'd love to learn that
This is nice! We are already getting used to this behaviour using banking apps and wallets. It will be a good push for standardized logins as well. Congrats on the launch!
This is awesome! Congrats on the launch.
I've been using SuperTokens off/on for the past year or so. Since I develop mostly NextJS apps, passwordless auth will match up really well with what NextAuth offers. I prefer passwordless auth since it seems more secure than the traditional username & password option, so excited to keep using SuperTokens and now that this is offered I'll be enabling this in my project alongside the social login.
@manav_sharma1 SuperTokens follows all the best practices by default. So you just have to follow the docs and you should be good to go. Some of the best practices we follow:
- Keeping passwordless codes (OTP or magic links) short lived
- Limiting the number of OTP tries per login attempt. After the number of tries has been reached, a new OTP is generated.
- Preventing email clients from consuming the magic link if they open the magic link to scan them.
- Removing unused passwordless codes after they have expired.
- Revoking all passwordless codes for a user once they have successfully consumed any one of them.
- Allowing our users to easily implement their own spam protection for SMS based login.
And on the session side:
- Using httpOnly for session cookies.
- Preventing against CSRF attacks.
- Using rotating refresh tokens for session management (to detect session hijacking)
Finally! :D
A lot of time was spent primarily on creating the best experience for developers. Thinking from the most common use cases to the most far fetched ones (you can add phone no. + email based passwordless together), it was fun to be a part of this.
And though we launched passwordless today, for all we know, you may need a password based solution. For that, do check out all the other βrecipesβ we have on our guides page.
Hi @advait_ruia, congrats on the launch π
I am a fan of passwordless and yet I find that in terms of UX is not necessarily better.
With email and password:
1. User signs up with username and password
2. User is in the product
(Assuming email verification can be done asynchronously)
With passwordless:
1. User signs up with email
2. User needs to go out of the product to find the OTP - at this point, many bad things can happen. The user is distracted by another email; the mail gets to spam; the mail takes a few minutes to arrive breaking the flow on the onboarding, etc.
In what sense do you think passwordless has a better UX? Do you know if there is any study comparing the drop-off rate of password and passwordless approaches?
@marco_ancona2 Hey Marco! Passwordless is not always better UX. It depends on your app and your customers.
You are correct that the user may need to switch to another app and get distracted. The flip is that they may not remember their password, which could also create a similar or worse issues
In certain cases, passwords are a better experience and in other cases, passwordless is preferable. For eg: if your user is on a mobile app, sending them an OTP to their phone number allows them to login without needing to leave the app. The OS will autofill the OTP from the SMS into the app or at the very least the user will see the OTP as a notification and can type it in without navigating away. In this case, passwordless could be preferable.
Intercom