OAuth 2将身份验证与服务器-服务器API调用的授权分开

Question

语境

嗨，我正尝试为我们公司的产品设计一种具有以下三个属性的访问控制解决方案：

• 客户可以（通过其IdP解决方案）带来自己的身份，也可以与他们联合以获取身份。这使他们可以完全控制访问权限，并减轻了我们的用户管理（目前对我们的帮助台来说是一个很大的工作量！）
• 我们可以集中控制客户可以使用哪些产品，也就是我们可以管理授权。这使我们高枕无忧，因为我们不会冒用产品的风险，并且可以集中使用目前隔离和昂贵的炉灶管道中的操作流程。
• 我们将产品与各种客户身份识别协议的变幻莫测隔离开来，也就是我们通过某种形式的集线器或网关来运作，这些集线器或网关在特定于客户的行为与我们的内部产品之间进行转换。这样可以确保在所有产品上都能为客户提供良好的支持，并且只需要与网关团队进行交互，而我们的产品团队也只需与网关团队进行交互并使用单个协议即可。

我目前的想法是在网关服务中支持OpenID Connect（OIDC）/ OAuth 2协议，通过销售/运营工作流在带外创建客户IdP端点与我们的网关之间的信任关系，以及网关之间的信任关系。和内部产品是我们内部开发工作的一部分。

消息流变为：

• 客户从其IdP获得身份令牌（取决于他们的方式）。
• 客户将身份令牌提供给我们的网关服务，并在获得产品授权的情况下接收产品的访问令牌。
• 客户向产品出示访问令牌以获得服务。

注意：除了使用SAML断言以及IdP和RP的SAML联合，并且与所涉及的IdP一样，这与Gov.UK验证身份解决方案类似。

我还期望在以后的阶段支持协议/令牌转换（例如：SAML断言-> OIDC令牌），或具有专有身份提供者机制的客户，并集成我们自己的IdP（AzureAD）以供员工访问。

所以有什么问题？

似乎OIDC / OAuth 2没有现有流程，可以在没有最终用户的情况下跨两个系统（实际上是安全性边界）明确区分身份验证和访问授权，并且这也不是存在用户的设计的一部分（所有这些图有一个完成两个任务的授权服务器）。

我们的大多数客户将从他们的后端调用我们的服务，不存在最终用户或浏览器，因此我们无法使用支持id_tokens（或auth代码）的交互式OIDC流，而剩下的client_credentials流，并且仅处理访问令牌。

我是否全部错了（OIDC / OAuth方法是否错误）？

我们是否应该将客户的访问令牌转换为网关中的其他访问令牌（因为他们无法创建id_tokens）？

我知道令牌交换的标准草案（https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14），这会有所帮助吗？

Answer 1

我会考虑JWT和/或SAML 断言授予类型。这些旨在使用由已执行用户身份验证的受信任第三方身份提供商颁发的令牌从 OAuth 服务器获取访问令牌。这将产生如下所示的架构：

                                                                   (4) Look up prod-
                                                                      ucts           +------------+
                                                                        +----------->+            |
                                                                        |            | API/DB of  |
                                                                        |            |   products |
   +----------------+                                    +--------------+---+        |            |
   |      Some      |                                    |                  |        |            |
   |    Trusted     |            (3)JWT or SAML grant    |    Your OAuth    |        +---+--------+
   |      IDP       <--+          +--------------------->+      server      |            |
   |                |  |          |     +----------------+                  <------------+
   +---+------------+  |          |     |                +--------+------+--+     (5) Allowed products
       |               |  (1)     |     | (7) Access token        ^      |
       |             OIDC, SAML   |     | scoped for your APIs    |      | (6) Burn allowed products into
       |             or|other     |     |                         +<-----+ access token as claims
    JWT or SAML        |          |     |
(2) token intended+----+----------+-+   |                +------------------+              +----------------+
    for your OAuth|                 +<--+                |                  |              |                +<-----+
       | server   |      Some       |                    |                  |              |                |      |
       +---------->     Client      +------------------->+  Your gateway    +------------->+    Your APIs   |      ^  (11) Fine grained
                  |                 | (8) Attempt to     |                  |  (10) Attempt|                |      |  authorization using
                  |                 | access your APIs   |                  |  to access   |                +------+  claims in access
                  +-----------------+ with your access   +--+-----^---------+  APIs with   +----------------+         token
                                      token as proof of     |     |            access token
                                      authentication        |     |            that's been authorized to
                                                            +-->--+            an extent
                                                           (9) Course grained
                                                           authorization using
                                                           scope, URL & HTTP method

在步骤 9 和 10 之间，如果您不使用拆分令牌方法，我可能会将访问令牌转换为虚拟令牌。这将防止客户端看到您的访问令牌中只需要您自己的内部 API 知道的内容。