If you ever wanted to use Discourse as your authentication provider - now you can!
Over the last week I’ve written a small service which can be used to act as an OpenID connect/OAuth provider with discourse as a backend.
You can check out the code here:
Note that my primary use case was to authenticate to Nextcloud using Discourse, so it might not be working for your use case.
If something is not working as expected, or it is missing that certain feature to make it work for you, feel free to create an issue in the GitHub repository.
Awesome initiative! I always wanted Discourse to be usable as an OAuth provider, so it can easily be integrated with more tools. Making it an external small service makes a lot of sense too!
I like the sound of this and hope some communities decide to try it out!
I’d love to see OIDC supported by Discourse officially in addition to our bespoke Discourse Connect functionality, so we can offer a turnkey solution to our customers on standard and teams without having to rely on okta or the like.
Distrust is a separate service, so you need to deploy it as such. You can run it in a container as described in the README file. Note that for secure operation, you will also need a reverse proxy handling SSL Termination (I might implement this directly sometime in the future).
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.
