Easier account signup using email codes

[rishabh]

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:

:

1. They enter an email address and click Continue.
2. A six-digit code lands in their inbox. They paste it (or type it) and the form auto-submits when the last digit is filled.
3. If they have second-factor authentication enabled (TOTP, backup codes, or security key), the standard 2FA step appears next.

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.

Random usernames for new accounts

New members who sign up without a recognisable username in their email are now given a friendly generated name like “QuietFalcon42” instead of a generic placeholder like user1. The account-ready step prefills the suggestion and includes a dice button to roll a new one.

The word lists behind the suggestions are configurable via the random_username_adjectives and random_username_nouns site settings, so communities can tune them to their tone or language. To opt out and keep the old numbered fallback, disable enable_random_usernames.

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?

[darkpixlz (Pyx)]

I just gave it a try on my site. I’m not sure what everybody else thinks, but this seems like a pretty big downgrade to me as a password manager user…

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.

[dfabulich (Dan Fabulich)]

Email codes, AKA “magic links”, are decent, but nudging users towards passkeys makes the experience way, way better.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

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.

Nudging users towards passkeys is the same as nudging users towards using a password manager, because passkeys are just passwords that require a password manager.

[Don]

Hello

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.

Thanks!

[pmusaraj (Penar Musaraj)]

@dfabulich

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.

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).

@dfabulich

Nudging users towards passkeys

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.)

[DomMcD (Dominic McDevitt)]

My only issue with this feature is that it removes the name and username fields from my signup page. Is this intentional? I don’t want to force users to spelunk around in settings right after signup just to set a username that isn’t “user63”.

[kddkd (用户16)]

This email verification code registration method is a change I’ve always wanted!

[Moin]

Without this change, the “I forgot my password” and the “Email me” link had the same size. Now the latter is larger. Is that intentional?

[Moin]

It was fixed in

UX: Match font size of one-time code login link (#41879)

[rishabh]

Thanks for the feedback, yes it is intentional as part of a faster way to create accounts.

@DomMcD

I don’t want to force users to spelunk around in settings right after signup just to set a username that isn’t “user63”.

Noted, yes we are exploring ideas to make this next step simpler or set initial usernames using a different method.

[Moin]

I agree. Those generic usernames make interacting with users more confusing. Since users by default only have 3 days to update the names, I expect that frequently they will notice after that time has passed, so staff needs to take care of renaming them.
I really enjoyed that Offering blank username suggestions rather than ‘UserN’ at signup prevented that from happening for example here on meta. The last userXXX was created on January 7th before that fix was merged. Then there was no new userXXX until this feature was enabled, and since then there are 12 new ones.

[Thomas_Rother (Thommie Rother)]

This feature is extremely useful. More and more platforms are using the ‘one-time code via email’ function to offer secure logins with MFA, without the need to have a specific device (with the appropriate authenticator) to hand.

[rishabh]

@DomMcD

I don’t want to force users to spelunk around in settings right after signup just to set a username that isn’t “user63”.

@Moin

I agree. Those generic usernames make interacting with users more confusing. Since users by default only have 3 days to update the names, I expect that frequently they will notice after that time has passed, so staff needs to take care of renaming them.

Are you not seeing this step during account creation?

[Moin]

This is a weird quote: it looks like DomMcD quoted me, which is not true.

I haven’t tested the steps. I was commenting on what I noticed about new users here on Meta. It doesn’t matter if I see a field during sign-up. I have to deal with what others do with that field.

I also wonder how names are handled. While not every user seems to use the generated usernames, I notice even more which have a name that is userXXX.

They seem to get that even when changing the username, and this results in the same number being used again and again until the username is taken, and then it starts again with the next number.

For example, 0102100988082, mohamedasarudeen and user603 all have user603 as their name.

I know they could change the name, but again, I cannot change my experience in interacting with them.

[rishabh]

Thank you for the reports everyone, a fix will be merged very soon:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

Update

Thanks to @keegan’s latest work, we now have a username generation feature in this step that prefills a suggestion:

@rishabh

Random usernames for new accounts

New members who sign up without a recognisable username in their email are now given a friendly generated name like “QuietFalcon42” instead of a generic placeholder like user1. The account-ready step prefills the suggestion and includes a dice button to roll a new one.

The word lists behind the suggestions are configurable via the random_username_adjectives and random_username_nouns site settings, so communities can tune them to their tone or language. To opt out and keep the old numbered fallback, disable enable_random_usernames.