Je souhaiterais demander le support d’un flux local sans mot de passe véritable dans Discourse, sans devoir dépendre d’un fournisseur d’identité externe comme Microsoft, Google, etc.
À l’heure actuelle, autant que je puisse en juger, Discourse possède déjà certains éléments de ce système, mais pas la combinaison de configuration nécessaire.
Ce qui existe aujourd’hui
Discourse dispose déjà de :
- des comptes locaux
- de liens de connexion par e-mail / d’un comportement de connexion sans mot de passe via
enable local logins via email - de flux d’invitation où le mot de passe peut être différé
- de provisionnement automatique d’authentification externe via OIDC / OAuth / SAML / DiscourseConnect
Mais l’élément manquant est que la connexion locale par e-mail est toujours liée aux connexions locales en général, ce qui signifie que je ne peux pas clairement dire :
- autoriser la connexion locale par lien magique par e-mail
- autoriser l’inscription/localisation locale par lien magique par e-mail
- ne pas autoriser l’authentification locale par mot de passe
C’est cette combinaison que je souhaite.
Le cas d’usage
Je souhaite que Discourse prenne en charge nativement ce modèle :
- L’utilisateur arrive sur le site
- L’utilisateur saisit son e-mail
- Discourse lui envoie un lien de connexion à usage unique / à durée de vie limitée
- S’il n’a pas déjà de compte, Discourse en crée un
- L’utilisateur est connecté
- Les connexions futures peuvent continuer de la même manière
- Aucun mot de passe local n’est requis, sauf si l’administrateur souhaite explicitement en autoriser un
Autrement dit :
compte local
vérification locale de la propriété de l’e-mail
aucun mot de passe local requis
Pourquoi cela compte
Pour le moment, si quelqu’un souhaite une expérience sans mot de passe, la solution de contournement la plus propre semble être l’utilisation d’un fournisseur d’identité externe. Mais cela n’est pas idéal pour tous les sites.
Quelques raisons :
- toutes les communautés ne veulent pas dépendre de Microsoft / Google / Auth0 / etc.
- certaines communautés souhaitent un flux d’authentification local plus simple et respectueux de la vie privée
- certaines communautés souhaitent réduire les frictions liées aux mots de passe sans externaliser l’identité
- certains administrateurs souhaitent prendre en charge des utilisateurs qui sont mauvais avec les mots de passe mais qui peuvent gérer des liens par e-mail sans problème
Il existe déjà un précédent pour la connexion sans mot de passe dans Discourse via des liens par e-mail, ce qui fait que cela ressemble davantage à un mode produit manquant qu’à un concept entièrement nouveau.
Ce que je demande
Je pense que cela pourrait être résolu en dissociant ces concepts :
Comportement actuel
enable local loginsenable local logins via email
Comportement demandé
Permettre aux administrateurs de contrôler indépendamment :
- autoriser la connexion locale par mot de passe
- autoriser la connexion locale par lien par e-mail
- autoriser l’inscription locale par mot de passe
- autoriser l’inscription locale / création de compte par lien par e-mail
Modèle de paramètres souhaité (exemple)
Quelque chose comme :
enable local password loginsenable local email loginsenable local password signupenable local email signup- peut-être
local email signup creates account automatically - peut-être
local email signup requires staff approval - peut-être
local email login link expiry minutes
Pas nécessairement ces noms de paramètres exacts, juste le concept.
UX souhaitée
Connexion
Un utilisateur devrait pouvoir choisir :
- continuer avec un mot de passe
- ou me envoyer un lien de connexion par e-mail
Si la connexion par mot de passe est désactivée, seule l’option par lien par e-mail est affichée.
Inscription
Un utilisateur devrait pouvoir choisir :
- créer un compte avec un mot de passe
- ou créer un compte via un lien par e-mail
Si l’inscription par mot de passe est désactivée, le site devrait simplement procéder à une inscription par lien par e-mail.
Pourquoi les invitations ne suffisent pas
Les invitations aident à l’intégration, mais elles ne sont pas la même chose qu’un véritable mode d’authentification local sans mot de passe.
À ma connaissance :
- les invitations servent principalement à l’acceptation / au rachat
- elles ne constituent pas l’identifiant de connexion continu de l’utilisateur
- après l’expiration de la session, les utilisateurs ont toujours besoin d’un chemin de connexion normal
Les invitations sont donc liées, mais elles ne résolvent pas entièrement le problème.
Pourquoi l’authentification externe ne suffit pas
Oui, OIDC / OAuth / SAML peuvent fournir des expériences sans mot de passe ou basées sur l’OTP, et auth skip create confirm aide beaucoup dans ce cas.
Mais cela signifie que le site dépend désormais d’un fournisseur d’identité tiers.
Pour certaines communautés, cela convient. Pour d’autres, c’est une complexité inutile et une dépendance indésirable.
Réflexions sur la sécurité
Je suis conscient que l’authentification par lien par e-mail comporte des implications en matière de sécurité, mais Discourse dispose déjà de modèles connexes tels que :
- réinitialisation du mot de passe par e-mail
- connexion par lien par e-mail
- acceptation d’invitation par e-mail
Ainsi, cela n’introduirait pas l’idée de preuve de contrôle par e-mail à partir de zéro.
Des mesures de protection raisonnables pourraient inclure :
- des liens à durée de vie limitée
- des limites de taux agressives
- des jetons à usage unique
- une authentification à deux facteurs (2FA) optionnelle après une connexion par lien par e-mail
- un délai de rétractation optionnel avant de modifier l’e-mail / le mot de passe après une authentification par lien magique
- visibilité et journaux pour les administrateurs concernant les connexions par lien par e-mail
En résumé
Je demande un mode local sans mot de passe de premier plan dans Discourse, où :
- les utilisateurs s’authentifient en prouvant le contrôle de leur e-mail
- Discourse peut créer des comptes locaux à partir de ce flux
- les administrateurs peuvent désactiver entièrement l’authentification locale par mot de passe
- cela fonctionne sans avoir besoin de Microsoft / Google / d’un autre fournisseur SSO
Je pense que cela serait une fonctionnalité très utile pour les communautés qui souhaitent une intégration à faible friction sans externaliser l’identité.