OpenID Connect第一方和第三方依赖方体系结构

Question

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

为了让用户访问并登录X1和X2，他们应该有一个有效的Company-X帐户，比如你需要谷歌帐户如何使用Gmail和谷歌+。简而言之，X1和X2本身没有身份验证，它使用Company-X身份提供程序（ IP ）进行身份验证并进行会话。

在OpenID Connect（ OIDC ）条款中，X1和X2将成为依赖方（ RP ）。 X1是User-agent，X2是服务器。 Company-X IP包含授权服务器和资源（受保护的REST-API）。

• 我选择这些拨款类型是对的吗？ （见图表的图例）

• 这是此案例的推荐架构吗？ （具有登录的集中帐户的第一方应用程序，以及将来的第三方应用程序的IP）

  

Answer 1

授予类型的选择主要通过查看以下方面来执行：

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

在第一点，要考虑的事项之一是客户端应用程序运行的环境：

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

基于此和您所描述的内容，选择隐含授予RP X1似乎是合适的。

关于 RP X2 ，它不是那么明确，我们应该从这个应用程序想要访问的资源的角度来审查它。作为服务器端，此应用程序能够维护机密并因此符合客户端凭据的条件，但是，当应用程序想要访问与应用程序本身而不是特定用户相关联的资源时，此授权是合适的。

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

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

客户端凭据



（来源：Client Credentials Grant）

授权码授权



（来源：Authorization Code Grant）

从我的角度来看，与架构相关似乎是正确的方法。它使用公共标准并满足您的要求，因此我非常怀疑它有更好的选择。认证系统的一个大问题不是设计阶段，而是实施本身，特别是考虑到使其成为工作和＃34;需要大约20％的努力，剩下的80％确保你不会陷入困境。