I’d like to request support for a true local passwordless flow in Discourse, without having to rely on an external identity provider like Microsoft, Google, etc.
Right now, as far as I can tell, Discourse has pieces of this already, but not the actual configuration combination needed.
What exists today
Discourse already has:
- local accounts
- email login links / passwordless-style login behavior via
enable local logins via email - invite flows where password can be deferred
- external auth auto-provisioning via OIDC / OAuth / SAML / DiscourseConnect
But the missing piece is that email-based local login is still tied to local logins generally, which means I can’t cleanly say:
- allow local email magic-link login
- allow local email magic-link signup / onboarding
- do not allow local password auth
That is the combination I want.
The use case
I want Discourse to support this model natively:
- User arrives at site
- User enters email
- Discourse emails them a one-time / short-lived login link
- If they don’t already have an account, Discourse creates one
- User is signed in
- Future logins can continue the same way
- No local password is required unless the admin explicitly wants to allow one
In other words:
local account
local email ownership verification
no local password required
Why this matters
At the moment, if someone wants a passwordless experience, the cleanest workaround seems to be using an external identity provider. But that is not ideal for every site.
Some reasons:
- not every community wants to depend on Microsoft / Google / Auth0 / etc
- some communities want a simpler and more privacy-preserving local auth flow
- some communities want to reduce password friction without outsourcing identity
- some admins want to support users who are bad at passwords but can handle email links just fine
There’s already precedent for passwordless login in Discourse via email links, so this feels more like a missing product mode than a completely new concept.
What I’m asking for
I think this could be solved by decoupling these concepts:
Current behavior
enable local loginsenable local logins via email
Requested behavior
Let admins independently control:
- allow local password login
- allow local email-link login
- allow local password signup
- allow local email-link signup / account creation
Example desired settings model
Something like:
enable local password loginsenable local email loginsenable local password signupenable local email signup- maybe
local email signup creates account automatically - maybe
local email signup requires staff approval - maybe
local email login link expiry minutes
Not necessarily these exact setting names, just the concept.
Desired UX
Login
A user should be able to choose:
- continue with password
- or email me a login link
If password login is disabled, only the email-link option is shown.
Signup
A user should be able to choose:
- create account with password
- or create account via email link
If password signup is disabled, the site should just do email-link signup.
Why invites are not enough
Invites help with onboarding, but they are not the same thing as a real local passwordless auth mode.
From what I understand:
- invites are mainly for acceptance / redemption
- they are not the user’s ongoing login credential
- after session expiry, users still need a normal sign-in path
So invites are related, but they do not fully solve the problem.
Why external auth is not enough
Yes, OIDC / OAuth / SAML can provide passwordless or OTP-based experiences, and auth skip create confirm helps a lot there.
But that means the site is now dependent on a third-party identity provider.
For some communities that’s fine. For others it’s unnecessary complexity and an unwanted dependency.
Security thoughts
I realize email-link auth has security implications, but Discourse already has related patterns such as:
- password reset via email
- login via email link
- invite acceptance via email
So this would not be introducing the idea of email-based proof of control from scratch.
Reasonable safeguards could include:
- short-lived links
- aggressive rate limits
- single-use tokens
- optional 2FA after email-link login
- optional cooldown before changing email / password after magic-link auth
- admin visibility / logs for email-link sign-ins
In short
I’m asking for a first-class local passwordless mode in Discourse, where:
- users authenticate by proving control of their email
- Discourse can create local accounts from that flow
- admins can disable local password auth entirely
- this works without needing Microsoft / Google / another SSO provider
I think this would be a very useful feature for communities that want low-friction onboarding without outsourcing identity.