这很棒，比不起作用的 oauth2 插件好多了，但这个插件（配合 Keycloak）可以正常工作。
不过，支持多个 OIDC 源将是一个非常受欢迎的功能。
这是一个有趣的想法。您能否详细说明您的用例以解释其优势，如果可能的话，您想使用哪些登录源？
回答上面第 2 楼的问题：我们的使用场景，以及我们需要哪些登录源。
我们在欧盟境内托管了一个面向欧盟研究倡议的公共社区论坛，运行在欧盟境内的托管 Discourse 上。
我们需要同时启用两个 OIDC 提供商：
- EU Login，欧盟委员会的身份提供商。它供委员会工作人员、政策利益相关方以及欧盟资助项目的参与者使用。采用标准 OIDC，其发现文档位于
https://ecas.ec.europa.eu/cas/oauth2/.well-known/openid-configuration。 - EGI Check-in，一个联邦学术身份代理，它位于机构账户和 ORCID 之前。它被整个欧洲研究基础设施所使用。同样采用标准 OIDC。
这两个提供商互不覆盖对方的用户。政策官员使用 EU Login 登录，但没有机构研究身份；研究人员通过我们的代理使用大学账户或 ORCID 登录，但没有 EU Login。我们的社区由这两类人群组成，因此只选择一个提供商意味着会拒绝对论坛而言一半的目标用户。
这两个提供商都支持标准的 OIDC，且各自都能独立工作。阻碍我们的是 discourse-openid-connect 插件只暴露了一个未编号的设置命名空间：openid_connect_client_id，而不是 openid_connect_1_client_id 和 openid_connect_2_client_id。每个站点只能配置一个 OIDC 提供商。
我们希望支持多个提供商。最自然的形式是为每个提供商设置独立的命名空间，无论是编号设置还是由管理员管理的列表，让每个提供商都有自己独立的发现文档、客户端凭据、作用域（scope）和按钮标题。
早在 2021 年，Multiple openid-connect authentication providers 中就有过类似的先例，当时的需求是多个 Keycloak 领域（realms）。那是同一限制的不同表现形式。
如果需要，我们可以提供更多信息，或者测试实现方案，如果那能帮上忙的话。
1 个赞
你可以尝试搭建一个 Authentik 服务，并与这两个提供商进行“联合认证”。这样，你就可以为团队提供内部 SSO，同时为外部用户提供代理 SSO。考虑到需要自行托管 SSO，这可能会稍微复杂一些，但根据你的具体情况，这可能比修补 OIDC 插件要快。
话虽如此，我在 Discourse 的设置中到处都能看到（企业登录提供商）相关的选项，因此能够添加我们自己的提供商确实会很不错。也许可以 fork 一下 OIDC 插件并修改其中的名称？
4 个赞
谢谢你的建议。EGI Check-in 服务本身已经是一个 IdP 代理，支持使用许多 IdP。
目前的限制在于，EU Login 的政策不允许使用代理。他们要求与服务建立直接连接。
1 个赞
在这种情况下，如果另一个系统支持 OAuth2，你可以使用 Discourse OAuth2 Basic 进行配置，从而保留 EU EIDAS 的 OIDC。以前还有一个 SAML 插件，不过它可能已经被弃用了。
2 个赞
感谢你的建议。确实，我们目前正在探索使用 Discourse OAuth2 Basic 配合 EGI Check-in 的方案。
我想把这个案例提出来引起社区的注意，因为支持多个 OIDC 提供商的可能性在未来可能会让更多组织受益，并简化相关流程。
SAML 选项之前并未在我们的考虑范围内，它可能是一个值得考虑的第三种选择。我找到了这个插件：GitHub - discourse/discourse-saml: Support for SAML in Discourse · GitHub
2 个赞