客户端开发人员将受到影响，因为他们需要开发他们的应用程序以向两个 oAuth 提供程序注册用户，并且必须从两个提供程序获取授权码。[...]
正如 GnP 已经说过的那样，向多个 oAuth 提供者注册用户并从多个 oAuth 提供者处获取授权代码在理论上不是问题，因为 Open ID Connect 为您提供了标准协议，甚至为 api 端点提供了标准发现方法。您编写代码以获取授权代码并将其交换为 id 和访问令牌一次，然后针对每个兼容的提供程序运行它（您的里程可能会有所不同 - 我成功地将我的代码部署到 Google 和 Microsoft Azure 的 Open ID Connect 实现中，但是当我尝试雅虎时，雅虎并没有按照规范行事，也没有给出它不这样做的原因......
忽略这个警告，支持多个身份提供者而不仅仅是一个身份提供者基本上只是在用户数据库中使用 1:1 关系和 1:n 关系之间的区别 - 例如，而不是将单个 Open ID Connect 主题标识符附加到每个您的用户实体，设计您的数据库后端以允许附加任意数量的它们，并且每次您想要支持新的身份提供者时，基本上您所要做的（如果它的行为符合规范）就是给您申请 IDP 的发现文档所在的域名。
但如果客户想要使用用户现有的 OpenID IdP 来实现初始注册和登录身份验证，则用户必须授权两次访问他们的数据。
我发现授权是更难解决的问题，但不是因为你给出的原因，我拥有它只是因为我有一个预先存在的用户群，具有一组明确定义的访问权限。我的问题是：基本上，每个 Open ID 提供者都会给你一个随机字符串来标识一个用户，但是你如何将这些字符串与你的用户实体（以及他们的授权）相匹配？您从 IDP 获得的主题字符串看起来完全是随机的，您无法提前知道它们，因此如果您有一个已知的用户群并为其定义了多个访问权限，您如何匹配一个您无法预测的 ID授权框架中的给定用户实体？
（我解决这个问题的方法是使用 IdP 给我的电子邮件地址作为 id 令牌的一部分作为唯一的已知标识符，以便在我第一次看到新用户身份验证时将 IdP 的主题标识符链接到我的用户实体，但为了让它发挥作用，您必须相信 IdP 正确地验证了电子邮件地址 - 我不愿意为每个 IdP 打赌）。
所以是的，允许多个身份提供者确实会产生一些额外的工作，但主要是为不同的 IdP 设置不同的信任模型。在我的情况下，我隐式信任来自我的主要 IdP 的 id 令牌，并且我只接受一小部分其他 IdP，我不相信他们会向我提供身份令牌主题标识符之外的经过验证的信息，所以对于这些，我需要第二个解决方案来解决我上面列出的匹配/授权问题。
如果您没有使用预先存在的用户群，解决匹配问题的方法是允许用户通过将其全部链接到同一个用户帐户来合并他的多个身份。您可以通过让他使用一个用户帐户进行身份验证来做到这一点，然后在他通过身份验证时告诉他使用其他身份提供者进行身份验证。然后，您的应用程序可以将所有这些身份链接在一起，因为它们属于数据库中的同一个人/用户实体。