Me gustaría solicitar soporte para un flujo local sin contraseña real en Discourse, sin tener que depender de un proveedor de identidad externo como Microsoft, Google, etc.
Por ahora, por lo que puedo ver, Discourse ya tiene partes de esto, pero no la combinación de configuración necesaria.
Lo que existe hoy
Discourse ya cuenta con:
- cuentas locales
- enlaces de inicio de sesión por correo electrónico / comportamiento de inicio de sesión sin contraseña mediante
enable local logins via email - flujos de invitación donde la contraseña puede diferirse
- aprovisionamiento automático de autenticación externa mediante OIDC / OAuth / SAML / DiscourseConnect
Pero la pieza que falta es que el inicio de sesión local basado en correo electrónico aún está vinculado a los inicios de sesión locales en general, lo que significa que no puedo decir claramente:
- permitir inicio de sesión local mediante enlace mágico por correo electrónico
- permitir registro / incorporación local mediante enlace mágico por correo electrónico
- no permitir autenticación local con contraseña
Esa es la combinación que busco.
El caso de uso
Quiero que Discourse admita nativamente este modelo:
- El usuario llega al sitio
- El usuario ingresa su correo electrónico
- Discourse le envía un enlace de inicio de sesión de un solo uso / de corta duración
- Si aún no tiene una cuenta, Discourse crea una
- El usuario inicia sesión
- Los inicios de sesión futuros pueden continuar de la misma manera
- No se requiere contraseña local a menos que el administrador decida habilitarla explícitamente
En otras palabras:
cuenta local
verificación de propiedad local del correo electrónico
no se requiere contraseña local
Por qué esto es importante
En este momento, si alguien desea una experiencia sin contraseña, la solución más limpia parece ser usar un proveedor de identidad externo. Pero eso no es ideal para todos los sitios.
Algunas razones:
- no todas las comunidades quieren depender de Microsoft / Google / Auth0 / etc.
- algunas comunidades desean un flujo de autenticación local más simple y que preserve mejor la privacidad
- algunas comunidades quieren reducir la fricción de las contraseñas sin externalizar la identidad
- algunos administradores quieren apoyar a usuarios que tienen dificultades con las contraseñas pero pueden manejar enlaces por correo electrónico sin problemas
Ya existe un precedente para el inicio de sesión sin contraseña en Discourse mediante enlaces por correo electrónico, por lo que esto se siente más como un modo de producto faltante que como un concepto completamente nuevo.
Lo que estoy solicitando
Creo que esto podría resolverse desacoplando estos conceptos:
Comportamiento actual
enable local loginsenable local logins via email
Comportamiento solicitado
Permitir que los administradores controlen de forma independiente:
- permitir inicio de sesión local con contraseña
- permitir inicio de sesión local mediante enlace por correo electrónico
- permitir registro local con contraseña
- permitir registro local / creación de cuenta mediante enlace por correo electrónico
Modelo de configuración deseado (ejemplo)
Algo como:
enable local password loginsenable local email loginsenable local password signupenable local email signup- quizás
local email signup creates account automatically - quizás
local email signup requires staff approval - quizás
local email login link expiry minutes
No necesariamente estos nombres exactos de configuración, sino el concepto.
Experiencia de usuario deseada
Inicio de sesión
Un usuario debería poder elegir:
- continuar con contraseña
- o enviarme un enlace de inicio de sesión por correo electrónico
Si el inicio de sesión con contraseña está deshabilitado, solo se mostrará la opción de enlace por correo electrónico.
Registro
Un usuario debería poder elegir:
- crear cuenta con contraseña
- o crear cuenta mediante enlace por correo electrónico
Si el registro con contraseña está deshabilitado, el sitio simplemente realizará el registro mediante enlace por correo electrónico.
Por qué las invitaciones no son suficientes
Las invitaciones ayudan en la incorporación, pero no son lo mismo que un verdadero modo de autenticación local sin contraseña.
Por lo que entiendo:
- las invitaciones son principalmente para aceptación / canje
- no son las credenciales de inicio de sesión continuas del usuario
- después de que expire la sesión, los usuarios aún necesitan una ruta normal de inicio de sesión
Por lo tanto, las invitaciones están relacionadas, pero no resuelven completamente el problema.
Por qué la autenticación externa no es suficiente
Sí, OIDC / OAuth / SAML pueden proporcionar experiencias sin contraseña o basadas en OTP, y auth skip create confirm ayuda mucho en ese aspecto.
Pero eso significa que el sitio ahora depende de un proveedor de identidad de terceros.
Para algunas comunidades eso está bien. Para otras, es una complejidad innecesaria y una dependencia no deseada.
Reflexiones sobre seguridad
Sé que la autenticación mediante enlaces por correo electrónico tiene implicaciones de seguridad, pero Discourse ya tiene patrones relacionados como:
- restablecimiento de contraseña mediante correo electrónico
- inicio de sesión mediante enlace por correo electrónico
- aceptación de invitación mediante correo electrónico
Por lo tanto, esto no introduciría desde cero la idea de prueba de control basada en correo electrónico.
Se podrían incluir salvaguardas razonables como:
- enlaces de corta duración
- límites de tasa agresivos
- tokens de un solo uso
- 2FA opcional después del inicio de sesión mediante enlace mágico
- período de espera opcional antes de cambiar el correo electrónico o la contraseña después de la autenticación con enlace mágico
- visibilidad / registros del administrador para inicios de sesión mediante enlace por correo electrónico
En resumen
Estoy solicitando un modo local sin contraseña de primera clase en Discourse, donde:
- los usuarios se autentiquen demostrando el control de su correo electrónico
- Discourse pueda crear cuentas locales a partir de ese flujo
- los administradores puedan deshabilitar por completo la autenticación local con contraseña
- esto funcione sin necesidad de Microsoft / Google / otro proveedor de SSO
Creo que esto sería una función muy útil para las comunidades que desean una incorporación de baja fricción sin externalizar la identidad.