如果您一直希望将 Discourse 用作身份验证提供商——现在可以实现啦！
在过去的一周里，我编写了一个小型服务，它可以作为 OpenID Connect/OAuth 提供商使用，后端基于 Discourse。
您可以在此查看代码：
请注意，我的主要用例是通过 Discourse 认证 Nextcloud，因此它可能无法完全满足您的需求。
如果某些功能未按预期工作，或者缺少某个特定功能导致无法使用，欢迎在 GitHub 仓库中提交问题。
太棒了的主意！我一直希望 Discourse 能作为 OAuth 提供商使用，以便更容易地与更多工具集成。将其作为一个独立的小型服务来构建也非常合理！
6 个赞
我对此很感兴趣，希望一些社区能尝试一下！
除了我们定制的 Discourse Connect 功能外，我非常希望 Discourse 能官方支持 OIDC，这样我们就能为标准版和团队版客户提供一站式解决方案，而无需依赖 Okta 等第三方服务。
7 个赞
这太棒了！感谢你的付出！
我真的很希望看到它被内置到 Discourse 中，这样它就可以成为一个独立的 OIDC 提供商！
5 个赞
太棒了，我喜欢它支持按组访问的功能。
1 个赞
Distrust 是一个独立的服务，因此您需要将其作为独立服务进行部署。您可以按照 README 文件中的说明在容器中运行它。请注意，为了安全运行，您还需要一个处理 SSL 终止的反向代理（我未来可能会直接实现此功能）。
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”}