We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this:
1. User enters email
2. We send a verification code to their email
3. User enters code, is signed in "indefinitely" (very, very long cookie)
Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.
There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.
Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.
This is also (from the data that I have seen) by far the best approach to maximise ecommerce revenue.
Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again.
Any extra friction costs more in lost revenue than the benefits of having "signed up" users.
I would imagine that plenty of users these days wouldn't bother to save their order details on the grounds that "oh, I'll get a notification with those".
Personally, I appreciate getting an email with details and a link for tracking. It does get annoying when it turns into low-grade spam, though.
I run a small B2C app. Users sign up with their email address only, a password field isn't even present. This creates the account and logs in the user "indefinitely" on this device. If they ever need to login on another device, they can request a new password. This way, this removes a) signup friction und b) weak passwords, because most people never need to login on another device anyways.
It's "temporary". You can set a password later and use it to login with email + password and store it in your password manager. Only the initial signup and the first login on a new device will require the "reset password" workflow. Imho, that's the best of both worlds.
I agree it's inferior to a password manager but I think passkeys will usurp the role of password managers in the long term, and for everyone else who won't use either, a simple email is an easy ask -- better than having them go through password reset every time they use the site.
This is how I’ve implemented login several times now, and it comes from repeatedly having to undo a ton of assumptions about what a User Account is when attempting to modify a funnel to just actually work how people want it to on both sides of the equation.
Unless you’re operating in an anonymity preserving space, you can just do this and choose to integrate with passkey later.
The main disadvantage of this method is that you have to think about managing multiple users for an account sooner than you normally would, since sharing a password is no longer possible. I can’t think of a funnel or UX that isn’t ultimately improved by conscious effort here.
The other is of course that your security becomes limited by the weighted average of security of your users’ email providers, which will generally be better than you need. Passwords can then be your second factor here, when you finally need them, or you can use some other factor yet again. In B2B you can jump straight to SAML or OIDC connections.
In B2B or D2C contexts this has always just worked and the edge cases are generally worth solving for the benefits to acquisition.
Magic links make assumptions about how users are accessing your sign in. That the device opening the email is the device using the authorization. Or that the user is signing into a web page and not a native/mobile app.
Second this, used this approach on a tiny CRUD app that was essentially a single form. The amount of support requests (approx. zero) throughout the campaign was absolutely worth it.
I mean, it doesn’t really matter. Just do it as long as it works and when it stops working they can sign in again. The point is to quit hassling your users in the name of “security” if you’re not a security critical application. YMMV.
1. User enters email
2. We send a verification code to their email
3. User enters code, is signed in "indefinitely" (very, very long cookie)
Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multiple emails and sometimes creates a new account accidentally. This is an acceptable disadvantage as we've observed dramatic improvements in registration and sign in conversions.
There is some risk analysis to do here on the code lifetime and cardinality (better yet, use a lockout mechanism.) If your service isn't particularly important, I recommend this strategy.
Mail on iOS now supports this type of mechanism too (same as the Messages one-time code functionality) so it can be quite painless for some users as well.