Vorrei richiedere il supporto per un flusso locale senza password in Discourse, senza dover dipendere da un provider di identità esterno come Microsoft, Google, ecc.
Al momento, per quanto ne so, Discourse ha già alcuni elementi di questo flusso, ma non la combinazione di configurazione necessaria.
Cosa esiste oggi
Discourse dispone già di:
- account locali
- link di accesso via email / comportamento di accesso senza password tramite
enable local logins via email - flussi di invito in cui la password può essere differita
- provisioning automatico di autenticazione esterna tramite OIDC / OAuth / SAML / DiscourseConnect
Ma il pezzo mancante è che l’accesso locale basato su email è ancora legato agli accessi locali in generale, il che significa che non posso dire chiaramente:
- consentire l’accesso locale tramite link magico via email
- consentire la registrazione / onboarding locale tramite link magico via email
- non consentire l’autenticazione locale con password
Questa è la combinazione che desidero.
Il caso d’uso
Voglio che Discourse supporti nativamente questo modello:
- L’utente arriva sul sito
- L’utente inserisce l’email
- Discourse invia all’utente un link di accesso monouso / a breve durata
- Se non ha già un account, Discourse ne crea uno
- L’utente viene autenticato
- I futuri accessi possono continuare nello stesso modo
- Non è richiesta alcuna password locale, a meno che l’amministratore non voglia esplicitamente consentirla
In altre parole:
account locale
verifica della proprietà dell’email locale
nessuna password locale richiesta
Perché questo è importante
Al momento, se qualcuno desidera un’esperienza senza password, l’alternativa più pulita sembra essere l’utilizzo di un provider di identità esterno. Ma ciò non è ideale per ogni sito.
Alcuni motivi:
- non tutte le comunità vogliono dipendere da Microsoft / Google / Auth0 / ecc.
- alcune comunità desiderano un flusso di autenticazione locale più semplice e rispettoso della privacy
- alcune comunità vogliono ridurre l’attrito legato alle password senza esternalizzare l’identità
- alcuni amministratori vogliono supportare utenti che hanno difficoltà con le password ma possono gestire facilmente i link via email
C’è già un precedente per l’accesso senza password in Discourse tramite link email, quindi questo sembra più un modo di prodotto mancante che un concetto completamente nuovo.
Cosa chiedo
Penso che questo possa essere risolto disaccoppiando questi concetti:
Comportamento attuale
enable local loginsenable local logins via email
Comportamento richiesto
Permettere agli amministratori di controllare indipendentemente:
- consentire l’accesso locale con password
- consentire l’accesso locale tramite link email
- consentire la registrazione locale con password
- consentire la registrazione / creazione account locale tramite link email
Modello di impostazioni desiderato (esempio)
Qualcosa del genere:
enable local password loginsenable local email loginsenable local password signupenable local email signup- forse
local email signup creates account automatically - forse
local email signup requires staff approval - forse
local email login link expiry minutes
Non necessariamente questi nomi esatti di impostazioni, ma il concetto.
Esperienza utente desiderata
Accesso
Un utente dovrebbe poter scegliere:
- continua con la password
- oppure inviami un link di accesso via email
Se l’accesso con password è disabilitato, viene mostrata solo l’opzione del link email.
Registrazione
Un utente dovrebbe poter scegliere:
- crea account con password
- oppure crea account tramite link email
Se la registrazione con password è disabilitata, il sito dovrebbe procedere direttamente con la registrazione tramite link email.
Perché gli inviti non sono sufficienti
Gli inviti aiutano nell’onboarding, ma non sono la stessa cosa di un vero e proprio modo di autenticazione locale senza password.
Per quanto ne so:
- gli inviti servono principalmente per l’accettazione / riscatto
- non sono le credenziali di accesso continue dell’utente
- dopo la scadenza della sessione, gli utenti hanno ancora bisogno di un percorso di accesso normale
Quindi gli inviti sono correlati, ma non risolvono completamente il problema.
Perché l’autenticazione esterna non è sufficiente
Sì, OIDC / OAuth / SAML possono fornire esperienze senza password o basate su OTP, e auth skip create confirm aiuta molto in quel contesto.
Ma ciò significa che il sito diventa ora dipendente da un provider di identità di terze parti.
Per alcune comunità questo va bene. Per altre è una complessità non necessaria e una dipendenza indesiderata.
Considerazioni sulla sicurezza
So che l’autenticazione tramite link email ha implicazioni per la sicurezza, ma Discourse ha già modelli correlati come:
- reimpostazione della password tramite email
- accesso tramite link email
- accettazione invito tramite email
Quindi non si tratterebbe di introdurre da zero l’idea di prova di controllo basata sull’email.
Safeguard ragionevoli potrebbero includere:
- link a breve durata
- limiti di frequenza aggressivi
- token monouso
- 2FA opzionale dopo l’accesso tramite link email
- periodo di attesa opzionale prima di modificare email / password dopo l’autenticazione tramite link magico
- visibilità / log per gli amministratori sugli accessi tramite link email
In sintesi
Chiedo un modo locale senza password di prima classe in Discourse, in cui:
- gli utenti si autenticano dimostrando il controllo della propria email
- Discourse può creare account locali da questo flusso
- gli amministratori possono disabilitare completamente l’autenticazione locale con password
- questo funziona senza bisogno di Microsoft / Google / un altro provider SSO
Penso che questa sarebbe una funzionalità molto utile per le comunità che desiderano un onboarding a basso attrito senza esternalizzare l’identità.