¡Si alguna vez quisiste usar Discourse como proveedor de autenticación, ahora puedes!
Durante la última semana he desarrollado un pequeño servicio que puede actuar como proveedor de OpenID Connect/OAuth utilizando Discourse como backend.
Puedes ver el código aquí:
Ten en cuenta que mi caso de uso principal fue autenticarme en Nextcloud usando Discourse, por lo que es posible que no funcione para tu caso de uso.
Si algo no funciona como se espera o falta esa característica específica para que funcione para ti, no dudes en crear un problema en el repositorio de GitHub.
¡Qué iniciativa tan genial! Siempre quise que Discourse fuera utilizable como proveedor de OAuth, para que pudiera integrarse fácilmente con más herramientas. ¡Convertirlo en un servicio externo pequeño también tiene mucho sentido!
¡Me gusta mucho esta idea y espero que algunas comunidades decidan probarla!
Me encantaría que Discourse admitiera oficialmente OIDC, además de nuestra funcionalidad personalizada Discourse Connect, para poder ofrecer una solución llave en mano a nuestros clientes en los planes Standard y Teams, sin tener que depender de Okta ni de soluciones similares.
Distrust es un servicio independiente, por lo que debes implementarlo como tal. Puedes ejecutarlo en un contenedor como se describe en el archivo README. Ten en cuenta que, para un funcionamiento seguro, también necesitarás un proxy inverso que gestione la terminación SSL (es posible que lo implemente directamente en algún momento futuro).
Espero obtener la opinión de expertos sobre los problemas que estoy experimentando al intentar usar Discourse como proveedor de SSO.
Mi objetivo: Estoy configurando Discourse para manejar la autenticación de otra aplicación (LibreChat). Estoy utilizando la funcionalidad estándar del proveedor DiscourseConnect, con el servicio puente OIDC distrust actuando como el cliente que se comunica con Discourse.
El problema: El flujo de SSO funciona perfectamente hasta el último paso. El usuario es redirigido correctamente desde mi aplicación a Discourse y puede iniciar sesión correctamente con sus credenciales de Discourse. Sin embargo, después de iniciar sesión, se le redirige a la página de inicio de mi foro de Discourse (/) en lugar de a la return_sso_url que se proporcionó.
Dónde estoy atascado (lo que he descartado): He estado solucionando este problema durante un tiempo y he confirmado que no se trata de un error de configuración simple. He descartado definitivamente lo siguiente:
Secretos: Los secretos del proveedor de Discourse Connect están configurados correctamente. Estoy utilizando el dominio sin formato (por ejemplo, auth.my-site.com) sin ningún protocolo, y la clave secreta coincide perfectamente con la de mi servicio cliente.
Modo SSO: He confirmado que habilitar el proveedor de Discourse Connect está marcado y que la configuración incorrecta de “Cliente SSO” está deshabilitada.
Políticas de usuario: Me he asegurado de que must_approve_users esté deshabilitado, y mi usuario de prueba es un administrador con un correo electrónico completamente verificado.
Plugins: He deshabilitado todos los plugins de terceros no oficiales y he reconstruido el contenedor, pero el problema persiste.
La evidencia clave: Tengo dos pruebas definitivas que me tienen desconcertado:
Análisis del archivo HAR: Capturé todo el flujo de red en un archivo HAR. Muestra que la solicitud POST a /session para iniciar sesión es exitosa. El servidor responde inmediatamente con una redirección 302 Found, pero el encabezado Location es consistentemente /. Esto demuestra que Discourse está abortando intencionalmente la redirección SSO.
Registro de Rails vacío: Luego seguí el archivo production.log dentro del contenedor mientras intentaba iniciar sesión. Absolutamente nada se escribe en el registro durante este proceso. Esto me dice que Discourse no lo ve como un error; es una acción deliberada y silenciosa.
Mi pregunta: Dado que el inicio de sesión es exitoso, pero la redirección es incorrecta y no hay errores en los registros, ¿qué política interna de Discourse, verificación previa o configuración oculta podría estar causando que ignore la return_sso_url y redirija a la página de inicio en su lugar? Siento que he agotado todas las configuraciones estándar.
