# Decouple passwordless email login/signup from enable local logins

**URL:** https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556
**Category:** Feature
**Tags:** login
**Created:** [26 april 2026 om 13:33 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556 "2026-04-26T13:33:56Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [26 april 2026 om 13:33 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/1 "2026-04-26T13:33:56Z")

</div>

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](https://meta.discourse.org/t/13045?silent=true)

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:

1. User arrives at site
2. User enters email
3. Discourse emails them a one-time / short-lived login link
4. If they don’t already have an account, Discourse creates one
5. User is signed in
6. Future logins can continue the same way
7. 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 logins`
- `enable 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 logins`
- `enable local email logins`
- `enable local password signup`
- `enable 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.

---

_[View the full topic](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556)._