Discourse communities can now let users log in using a short emailed code instead of a magic link, offering a passwordless login flow which feels familiar to many other SaaS platforms and works alongside your existing second-factor setup.
In this topic, we’ll review the major changes and share how you can start using this today.
What’s changed
When this feature is enabled, members see a simpler flow:
A few details worth knowing: codes are valid for 10 minutes, expire after 5 failed attempts, and can only be redeemed once.
Turning on one-time login codes in your community
For now, this is considered an experimental change! Before rolling it out more widely, we’re welcoming your feedback to help us make improvements.
To turn this on, head to the Upcoming changes page in your admin area (/admin/config/upcoming-changes) and find the Enable local logins via code item. Update the Enabled for… field to opt your site in to this new design:
Before enabling, confirm that both enable_local_logins and enable_local_logins_via_email are also true as the feature cannot be turned on without them. If you’re using DiscourseConnect (enable_discourse_connect), this feature cannot be enabled.
Once the change is enabled, the code login path appears automatically.
What do you think?
Over to you: we’d love to hear what you think of this new feature. What do you like and dislike; what is working well, and what could be improved?
This new flow removes the current “generate email, type username, generate password, save” strategy that my password manager has pushed me into and forces you to type the email first before everything. I don’t have an issue with the email code thing (and in fact almost prefer it, especially if the code is included in the email subject) but I strongly oppose removing the other account data boxes. If I were a user with zero technical background I would also see myself not handing out my email to a box with no info like this because it isn’t a common design. Before this becomes a permanent thing, it’d be great if that was added back.
Email codes, AKA “magic links”, are decent, but nudging users towards passkeys makes the experience way, way better.
One of the biggest problems with email codes is that they don’t do what you’d want them to do in in-app browsers, including Gmail’s in-app browser.
Probably the most common problem people run into with magic links is they think they have logged into the site on their normal browser, but they’re actually logged in through an in-app browser. For example, someone might receive the login link to their email. They open up the Gmail app, click the “Sign in to 404 Media” button, and their phone loads the webpage. But this is loading the website in Gmail’s web browser, not your native Safari one.
Passkeys fix this issue.
To start, websites using magic links can make passkeys an optional, opt-in feature for the customers who have complained about how their magic links work today. To ensure it doesn’t cause any problems, as a sort of soft launch, they could make the feature 100% opt-in.
Slightly later on, once the people running the website are convinced that passkeys really help with the user experience issues around magic links, they can prompt users to add passkeys after signing in, once every 90 days or so, or whenever they sign-in using the cross-device sign-in feature of passkeys. The framing of such a prompt can be something like this for users on Apple devices: Want to avoid having to check your email next time? Set up a passkey to use Face ID or Touch ID to sign in quickly and securely.
I like this approach a lot! However, it bothers me a bit that the display name cannot be changed before the registration is finished. I think it would be great to add an option to change it during the process.
In my community, I have disabled the Prioritize username in UX site setting, which means the Full Name/Display Name is prioritized across the UI. Because of this, automatically assigned names like “user21” look pretty bad on the front-end if the user doesn’t have an immediate option to customize it.
This new flow does not send a magic link. It only sends the code. The user stays on the same page, and copy/pastes the code from their email to the signup form. So this new approach does help with in-app browsers (it’s one of the main advantages of the change).
This is certainly something we would like to do next, in the password step of the signup. Apps and websites have ramped up their support of passkeys, I keep seeing the passkeys nudge in many contexts, so it makes sense to add to Discourse as well. (Critical mass of support is very helpful in this switch from passwords to passkeys.)
What’s changed
Turning on one-time login codes in your community
Before enabling, confirm that both 
What do you think?
