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).
{“content”:“Espero obter a opinião de especialistas sobre os problemas que estou enfrentando ao tentar usar o Discourse como um provedor de SSO.\n\nMeu Objetivo: Estou configurando o Discourse para lidar com a autenticação de outro aplicativo (LibreChat). Estou usando a funcionalidade padrão do provedor DiscourseConnect, com o serviço de ponte OIDC distrust agindo como o cliente que se comunica com o Discourse.\n\nO Problema: O fluxo de SSO funciona perfeitamente até a última etapa. O usuário é redirecionado corretamente do meu aplicativo para o Discourse, e eles conseguem fazer login com sucesso usando suas credenciais do Discourse. No entanto, após o login, eles são redirecionados para a página inicial do meu fórum Discourse (/) em vez de voltar para o return_sso_url que foi fornecido.\n\nOnde Estou Empacado (O Que Eu Já Descartei): Tenho solucionado este problema há algum tempo e confirmei que não se trata de um erro de configuração simples. Eu definitivamente descartei o seguinte:\n\n* Segredos: Os segredos do provedor discourse connect estão configurados corretamente. Estou usando o domínio simples (por exemplo, auth.my-site.com) sem nenhum protocolo, e a chave secreta corresponde perfeitamente à do meu serviço cliente.\n* Modo SSO: Confirmei que habilitar provedor discourse connect está marcado, e as configurações incorretas de "Cliente SSO" estão desabilitadas.\n* Políticas de Usuário: Certifiquei-me de que must_approve_users está desabilitado, e meu usuário de teste é um administrador com um e-mail totalmente verificado.\n* Plugins: Desabilitei todos os plugins de terceiros não oficiais e reconstruí o contêiner, mas o problema persiste.\n\nA Evidência Chave: Tenho duas evidências definitivas que me deixaram perplexo:\n\n1. Análise do Arquivo HAR: Capturei todo o fluxo de rede em um arquivo HAR. Ele mostra que a solicitação POST para /session para login é bem-sucedida. O servidor responde imediatamente com um redirecionamento 302 Found, mas o cabeçalho Location é consistentemente /. Isso prova que o Discourse está intencionalmente abortando o redirecionamento SSO.\n2. Log Rails Vazio: Em seguida, acompanhei o arquivo production.log dentro do contêiner enquanto tentava um login. Absolutamente nada é escrito no log durante este processo. Isso me diz que o Discourse não vê isso como um erro; é uma ação deliberada e silenciosa.\n\nMinha Pergunta: Dado que o login é bem-sucedido, mas o redirecionamento está incorreto e não há erros nos logs, qual política interna do Discourse, verificação prévia ou configuração oculta poderia estar fazendo com que ele ignore o return_sso_url e redirecione para a página inicial em vez disso? Sinto que esgotei todas as configurações padrão.\n\nObrigado antecipadamente por quaisquer ideias!”,“target_locale”:“pt_BR”}
