通过登录插件将JWT声明映射到Discourse用户

SSO
,
1

我一直在寻找一个SSO插件，它允许我利用来自我的IdP的声明来为我的Discourse用户提供服务。

在OIDC插件中，你基本上被锁定在userinfo端点。这不算坏，但我试图使用我们身份存储中的其他信息，而userinfo的结果无法调整。我曾试图强制OIDC插件使用id_token_info来伪造用户，但没有成功。

我回到了oauth插件，但表面上看它有相同的基本限制，即它依赖于来自特定端点的用户信息。我正在努力寻找一个能返回JWT声明内容的插件，但这并不是一个正常的用例，所以我不抱太大希望。

我最初认为oauth basic上的“callback userinfo paths”可以用来将声明映射到用户，但似乎总是在响应中得到null值并导致插入失败。我可以解码IdP的令牌并看到正确的声明，在这种情况下是在JSON的根部，如iss、exp等，但无法将它们连接到ActiveRecord端。

我正在查看jwt，但它似乎根本没有声明到用户的映射。基本上，如果你得到一个200，你就成功了，但这也不是我想要的。

我还发现了omniauth-jwt](GitHub - discourse/discourse-omniauth-jwt: An OmniAuth strategy that uses JSON Web Token for Single Sign-On)，它似乎更接近我的目标，尽管它看起来不是一个插件，也没有积极维护。也许我可以修复一些东西，但这比我希望的要困难得多。

有人能给我指明一个当前维护的插件方向，用于将JWT声明映射到用户，或者我可能在现有插件中出错了什么吗？

2

我没有主意，但我会这样做：获取 GitHub - discourse/all-the-plugins 并搜索 OmniAuth。这将给你一堆插件，它们使用这将给你 https://github.com/discourse/discourse-jwt，这可能就是你想要的。

3

是的，我已经看过了。\n\n除非我今天特别迟钝，否则它只涵盖了具有固定属性的身份验证。我找不到任何方法可以进行声明映射。如果我要分叉某个东西，那很可能是我开始的地方，但我想确保我没有错过一些显而易见的东西。

1 个赞
4

另外，为偶然发现此主题的各位提供一些额外背景信息。

OAuth basic 似乎仅支持从定义的用户数据端点获取属性，并且不支持映射 JWT 声明。因此，它类似于 OIDC 插件，但不是使用发现文档提供的 userinfo 位置，而是可以定位任何 JSON 端点，然后通过路径进行映射。在设置中添加“在标头中包含身份验证”，您就可以访问类似 https://graph.microsoft.com/v1.0/me 的位置，我们使用它来处理基于 Entra 的 OAuth。

现在，Entra ID 为核心对象提供了一些可扩展性，但这不像添加可选声明那么容易，而且据我所见，这将是一个全局更改。因此，我不确定这是否是我们真正的选择。再往回看，成熟的路径是只使用 JWT 插件，这似乎是唯一的途径，但它需要一些 PR 工作来添加声明映射支持。基本上，与现有的 oauth2-basic 允许将 Discourse 字段映射到 JSON 属性的方式相同，它需要允许对字段到 JWT 声明进行更多自定义。

现在这是一条可行的路径，但我遇到了另一个我认为会阻止所有事情的问题。

在 oauth2-basic 工作后，它会提示新用户，并发现已存在一个用户使用现有 OIDC 插件使用的电子邮件。即使它们共享相同的邮件属性，我认为它无法在同一 Discourse 用户之间切换提供商。让每个人从头开始并不是一个真正的选择，虽然我可能可以通过某种方式在 user_associated_accounts 中迁移 OIDC 提供商的 OAuth 提供商记录，但这感觉就像在自找麻烦。因此，即使 JWT 具有声明映射支持，所有现有用户都固定在 OIDC 提供商上，如果没有一些数据库操作或构建一个“现有用户”处理程序来允许更改关联帐户，您似乎就卡住了。

5

这很奇怪。它应该匹配电子邮件地址并连接到同一个帐户。OAuth 登录就是这样工作的。

6

我曾希望他们能通过允许每个 Discourse 用户拥有多个 user_associated 记录（按 provider_id）或提供一个“链接”提示来允许从一个提供商切换到新提供商来实现关联。但在我的测试中并非如此，它只是提示电子邮件已被使用，并要求创建新用户。

如果我停留在同一个插件上，我相信这会很顺利，但在这种情况下，它们是唯一的提供商 ID，每个都有自己的元数据。

1 个赞