Ich möchte Unterstützung für einen echten lokalen passwortlosen Ablauf in Discourse anfragen, ohne auf einen externen Identitätsanbieter wie Microsoft, Google usw. angewiesen zu sein.
Soweit ich das beurteilen kann, verfügt Discourse bereits über Teile dieser Funktionalität, jedoch nicht über die notwendige Kombination aus Konfigurationen.
Was heute existiert
Discourse bietet bereits:
- lokale Konten
- E-Mail-Login-Links / passwortähnliches Login-Verhalten über
enable local logins via email - Einladungsabläufe, bei denen die Passwortvergabe verzögert werden kann
- automatische Bereitstellung externer Authentifizierung über OIDC / OAuth / SAML / DiscourseConnect
Das fehlende Puzzleteil ist jedoch, dass der E-Mail-basierte lokale Login immer noch an lokale Logins im Allgemeinen gebunden ist. Das bedeutet, ich kann nicht sauber Folgendes festlegen:
- lokalen E-Mail-Magic-Link-Login erlauben
- lokale E-Mail-Magic-Link-Anmeldung / Onboarding erlauben
- lokale Passwortauthentifizierung nicht erlauben
Genau diese Kombination wünsche ich mir.
Der Anwendungsfall
Ich möchte, dass Discourse dieses Modell nativ unterstützt:
- Der Benutzer landet auf der Seite
- Der Benutzer gibt seine E-Mail-Adresse ein
- Discourse sendet ihm einen einmaligen / kurzlebigen Login-Link zu
- Falls noch kein Konto vorhanden ist, erstellt Discourse eines
- Der Benutzer ist angemeldet
- Zukünftige Logins können auf die gleiche Weise erfolgen
- Kein lokales Passwort ist erforderlich, es sei denn, der Administrator möchte eines explizit zulassen
Mit anderen Worten:
lokales Konto
lokale Verifizierung des E-Mail-Besitzes
kein lokales Passwort erforderlich
Warum das wichtig ist
Derzeit scheint der sauberste Workaround für eine passwortlose Erfahrung die Nutzung eines externen Identitätsanbieters zu sein. Das ist jedoch nicht für jede Seite ideal.
Einige Gründe:
- Nicht jede Community möchte von Microsoft / Google / Auth0 usw. abhängig sein
- Manche Communities wünschen einen einfacheren und datenschutzfreundlicheren lokalen Authentifizierungsablauf
- Manche Communities möchten die Passwort-Hürde senken, ohne die Identitätsverwaltung auszulagern
- Manche Administratoren möchten Benutzer unterstützen, die mit Passwörtern Schwierigkeiten haben, aber E-Mail-Links problemlos handhaben können
Es gibt bereits Präzedenzfälle für passwortloses Login in Discourse über E-Mail-Links, sodass dies eher wie ein fehlender Produktmodus als ein völlig neues Konzept wirkt.
Was ich anfrage
Ich denke, dies könnte durch Entkopplung dieser Konzepte gelöst werden:
Aktuelles Verhalten
enable local loginsenable local logins via email
Gewünschtes Verhalten
Administratoren sollten unabhängig steuern können:
- lokalen Passwort-Login erlauben
- lokalen E-Mail-Link-Login erlauben
- lokale Passwort-Anmeldung erlauben
- lokale E-Mail-Link-Anmeldung / Kontoerstellung erlauben
Beispiel für das gewünschte Einstellungsmodell
Etwas wie:
enable local password loginsenable local email loginsenable local password signupenable local email signup- eventuell
local email signup creates account automatically - eventuell
local email signup requires staff approval - eventuell
local email login link expiry minutes
Nicht unbedingt genau diese Einstellungsnamen, sondern das Konzept dahinter.
Gewünschtes UX (Benutzererfahrung)
Login
Ein Benutzer sollte wählen können:
- Mit Passwort fortfahren
- Oder mir einen Login-Link per E-Mail senden
Wenn der Passwort-Login deaktiviert ist, wird nur die Option für den E-Mail-Link angezeigt.
Anmeldung (Signup)
Ein Benutzer sollte wählen können:
- Konto mit Passwort erstellen
- Oder Konto über E-Mail-Link erstellen
Wenn die Passwort-Anmeldung deaktiviert ist, sollte die Seite einfach die Anmeldung per E-Mail-Link durchführen.
Warum Einladungen nicht ausreichen
Einladungen helfen beim Onboarding, sind aber nicht dasselbe wie ein echter lokaler passwortloser Authentifizierungsmodus.
Soweit ich das verstehe:
- Einladungen dienen hauptsächlich der Annahme / Einlösung
- Sie sind nicht die fortlaufende Login-Anmeldeinformation des Benutzers
- Nach Ablauf der Sitzung benötigen Benutzer weiterhin einen normalen Anmeldeweg
Einladungen sind also verwandt, lösen das Problem aber nicht vollständig.
Warum externe Authentifizierung nicht ausreicht
Ja, OIDC / OAuth / SAML können passwortlose oder OTP-basierte Erlebnisse bieten, und auth skip create confirm hilft dort sehr.
Das bedeutet jedoch, dass die Seite nun von einem Drittanbieter-Identitätsanbieter abhängig ist.
Für manche Communities ist das in Ordnung. Für andere ist es unnötige Komplexität und eine unerwünschte Abhängigkeit.
Sicherheitsüberlegungen
Mir ist bewusst, dass die E-Mail-Link-Authentifizierung sicherheitsrelevante Implikationen hat, aber Discourse verfügt bereits über verwandte Muster wie:
- Passwortrücksetzung per E-Mail
- Login per E-Mail-Link
- Annahme von Einladungen per E-Mail
Dies würde also nicht das Konzept des E-Mail-basierten Nachweises der Kontrolle von Grund auf neu einführen.
Angemessene Schutzmaßnahmen könnten sein:
- kurzlebige Links
- aggressive Ratenbegrenzungen
- Einweg-Token
- optionales 2FA nach dem Login per E-Mail-Link
- optionale Wartezeit vor der Änderung von E-Mail / Passwort nach Magic-Link-Authentifizierung
- Sichtbarkeit / Logs für Administratoren bei Logins per E-Mail-Link
Kurz gesagt
Ich bitte um einen erstrangigen lokalen passwortlosen Modus in Discourse, bei dem:
- Benutzer sich durch Nachweis der Kontrolle über ihre E-Mail-Adresse authentifizieren
- Discourse lokale Konten aus diesem Ablauf erstellen kann
- Administratoren die lokale Passwortauthentifizierung vollständig deaktivieren können
- dies ohne Microsoft / Google / einen anderen SSO-Anbieter funktioniert
Ich denke, dies wäre eine sehr nützliche Funktion für Communities, die ein reibungsarmes Onboarding wünschen, ohne die Identitätsverwaltung auszulagern.