Distrust:作为 OpenID Connect 提供商的讨论

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.

18 个赞

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!

6 个赞

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.

7 个赞

This is super cool! Thanks for doing this!

I would really like to see this built in to Discourse so that it could be its own OIDC provider!

5 个赞

Awesome, I love that it allows access by group.

1 个赞

@theSuess I am using discourse as stand alone then how Can I configure it?
image


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).

2 个赞

{“content”:“我希望有专家能看看我在尝试使用 Discourse 作为 SSO 提供商时遇到的问题。\n\n**我的目标:我正在设置 Discourse 来处理另一个应用程序(LibreChat)的身份验证。我使用的是标准的 DiscourseConnect 提供商功能,其中 distrust OIDC 桥接服务充当与 Discourse 通信的客户端。\n\n问题:SSO 流程在最后一步之前都运行正常。用户可以从我的应用程序正确重定向到 Discourse,并成功使用其 Discourse 凭据登录。但是,登录后,他们会被重定向到我的 Discourse 论坛主页 (/),而不是提供的 return_sso_url。\n\n我的困境(我已排除的):我已经对此进行了长时间的故障排除,并确认这不是简单的配置错误。我已经明确排除了以下几点:\n\n 密钥:discourse connect provider secrets 配置正确。我使用的是纯域名(例如 auth.my-site.com),没有协议,并且密钥与我的客户端服务中的密钥完全匹配。\n **SSO 模式:*我已确认勾选了 enable discourse connect provider,并且禁用了不正确的“SSO Client”设置。\n **用户策略:*我已确保 must_approve_users 被禁用,并且我的测试用户是具有完全验证电子邮件的管理员。\n **插件:我已禁用所有非官方的第三方插件并重建了容器,但问题仍然存在。\n\n关键证据:**我有两个确凿的证据让我感到困惑:\n\n1. **HAR 文件分析:**我在 HAR 文件中捕获了整个网络流。它显示登录的 POST 请求到 /session 是成功的。服务器立即响应 302 Found 重定向,但 Location 标头始终是 /。这证明 Discourse 正在故意中止 SSO 重定向。\n2. **空的 Rails 日志:**然后,我在尝试登录时跟踪了容器内的 production.log 文件。**在此过程中,日志中没有任何内容被写入。这告诉我 Discourse 并不认为这是一个错误;这是一个故意的、无声的操作。\n\n我的问题:**鉴于登录成功,但重定向不正确且日志中没有错误,是什么内部 Discourse 策略、预检检查或隐藏设置导致它忽略 return_sso_url 而重定向到主页?我觉得我已经用尽了所有标准设置。\n\n提前感谢任何想法!”,“target_locale”:“zh_CN”}