回答上面第 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）。那是同一限制的不同表现形式。
如果需要，我们可以提供更多信息，或者测试实现方案，如果那能帮上忙的话。