OpenID Connect 第一方和第三方依赖方架构

Question

我正在为 Company-X 的 X1 和 X2 应用程序编写 REST-API。

为了让用户访问和登录 X1 和 X2，他们应该有一个有效的 Company-X 帐户，例如您需要 google 帐户才能使用 gmail 和 google+。简而言之，X1 和 X2 本身没有身份验证，它使用 Company-X Identity Provider (IP) 进行身份验证并进行会话。

在 OpenID Connect (OIDC) 术语中，X1 和 X2 将是依赖方 (RP)。 X1 是用户代理，X2 是服务器。 Company-X IP 包含授权服务器和资源（受保护的 REST-API）。

• 我可以选择这些资助类型吗？ （见图表图例）

• 对于这种情况，这是推荐的架构吗？ （第一方应用有中心化账户登录，未来会为第三方应用提供IP）

Answer 1

授权类型的选择主要从以下几个方面进行：

1. 客户端应用程序的类型
2. 客户端应用程序想要访问哪些资源

首先要考虑的是客户端应用程序运行的环境：

• 基于浏览器 -> 隐式授权
• 服务器端 -> 授权代码授予和/或客户端凭据授予
• 原生应用 -> 主要是隐式授权，但也可以考虑授权码授权

基于此和您所描述的，为 RP X1 选择隐式授权似乎是合适的。

关于 RP X2 并不是很明确，我们应该从这个应用程序想要访问哪些资源的角度来审视它。在服务器端，此应用程序能够维护机密，因此有资格获得客户端凭据，但是，当应用程序想要访问与应用程序本身而非特定用户相关联的资源时，此授权适用。

如果此应用程序要访问与 Company-X 用户帐户关联的资源，则它应该使用授权码授予。

下图说明了客户端凭据授权与所有其他授权之间的这种实质性差异。您会注意到，没有涉及单独的资源所有者（理论上资源所有者就是客户端应用程序本身）。

---

客户凭证

（来源：Client Credentials Grant）

授权码授予

（来源：Authorization Code Grant）

---

关于架构，从我的角度来看，这似乎是正确的方法。它使用公共标准并满足您的要求，因此我非常怀疑是否有更好的选择。身份验证系统的大问题不是设计阶段，而是实现本身，特别是考虑到让它“工作”需要大约 20% 的工作，而剩下的 80% 是确保你没有搞砸。