oauth-2.0 - 未经资源所有者同意生成访问令牌的 OAuth 流程是什么？

Question

^{此问题中使用的角色和术语与RFC 6749相同。}

用例描述

我想允许受信任的 OAuth客户端请求授权服务器在未经他同意的情况下代表资源所有者 发出访问令牌（并且不涉及他和他的代理在流程中）。

调查

据我所知，在RFC 6749 第 4 节中没有任何与此流程匹配的授权：

授予	合适的	为什么
授权代码授予 RFC 6749，第 4.1 节	不	它涉及Resource Owner和User-Agent。
隐式授予 RFC 6749，第 4.2 节	不	它还涉及Resource Owner和User-Agent。
资源所有者密码凭证授予 RFC 6749，第 4.3 节	不	如果我们知道资源所有者的密码，它可能会起作用，但我们不知道。
客户端凭据授予 RFC 6749，第 4.4 节	不是，但..	它不涉及资源所有者或他的用户代理，但它不代表用户授予访问权限。
令牌交换 RFC 8693，第 2 节	不是，但..	subject_token它需要一个在我的场景中不存在的初始令牌（名为）。

客户凭证

Client Credentials授权很有希望，因为它允许客户端在不涉及资源所有者的情况下访问资源所有者拥有的受保护资源。虽然，据我了解，它并不代表资源所有者。引用RFC 6749，第 4.4 节：

当客户端请求访问受其控制的受保护资源或之前已与授权服务器安排的其他资源所有者（... ）。

因此，通过客户端凭据授予返回的访问令牌，例如不可能分配RFC 7662 第 2.2 节中定义的子声明值： OAuth 2.0 令牌自省 > 自省响应（参见RFC 7519，第 4.1.2 节：JWT）。

代币兑换

^{@Kaankom 建议了这笔赠款。请参阅@Kaankom 的回答。}

RFC 8693定义了如何使用模拟和委托获取安全令牌。对于我的用例来说，这听起来像是一个完美的授权，但这个授权需要一个“代表代理方身份”subject_token的参数作为输入。RFC 说：

通常，这将是被授权使用请求的安全令牌并代表主体行事的一方。

我没有这个令牌。但是，我也许可以打造一个新的（参见解决方案 5）。

非标解决方案

解决方案 1：新的 OAuth 授权

RFC 6749 第 4.5 节允许我们实现一种新的授权类型。与Client Credentials类似，这个全新的授权将需要在他的Access Token Request中添加一个额外的参数。此参数将定义资源所有者标识符，客户端将代表资源所有者对其进行操作。

解决方案 2：调整客户端凭据授予

除了实施新的 OAuth 授权（参见解决方案 1），我们还可以在现有的客户端凭据授权中添加一个可选参数。如果指定，授权服务器应验证允许客户端代表请求的资源所有者（由新参数指定）进行操作。

解决方案 3：调整授权码授予

使用授权码授权，我们可以绕过RFC 6749 第 4.1 节中定义的步骤 A、B 和 C ，让客户端请求访问令牌，而无需添加 acode或 a redirect_uri，但使用其客户端凭据和定义资源所有者。

解决方案 4：在 OAuth 之外实现它

浏览互联网，您可能会发现绕过 OAuth 机制及其access_token. 例如，在“如何从 APIKey 转换为 OAuth 2.0 客户端凭据”Acting-For一文中，他们在资源服务器调用上使用了额外的 HTTP 标头。

解决方案 5：使用自伪造令牌进行令牌交换授权

令牌交换授权需要但（据subject_token我所知）它没有定义授权服务器应该基于此令牌应用的策略。因此，理论上，客户端可以使用目标主体（声明）伪造未签名的 JWT，sub并获得签名的 JWT 作为回报。它看起来很有希望，但需要更多的调查。

笔记

我故意没有命名解决方案 1、2 和 3 中使用的参数。但是OpenID Connect Core 1.0 第 3.1.2.1 节/第 4 节定义了一个可选参数login_hint，名为“向授权服务器提示最终用户可能的登录标识符用于登录”。然而sub，这可能是另一个不错的提议。

Answer 1

您描述的用例听起来像是模仿。

看看这个：RFC 8693 - 令牌交换

Answer 2

您还没有真正描述用例/要求，尽管我将描述一些可能与您的用例相符的内容并给您一些想法。也许在声明和 API 授权方面考虑更多会以标准方式解决您的问题？

企业资产使用案例

有时资产不属于最终用户，实体有权对用户子集进行操作：

• 投资银行可能能够在更广泛的交易系统中为其员工更新某些详细信息

• 医生的手术可能能够在包含全国数据的系统中更新其患者的医疗详细信息

在 OAuth 术语中，银行/手术将使用客户端凭据授权，并通过客户端 ID 或可能在颁发的令牌中的自定义声明来标识。

如果银行 A 试图使用他们的访问令牌来更新银行 B 的交易员的详细信息，它将失败 API 授权，他们将收到状态为 404 的 HTTP 响应，意思是data not found for caller。

虽然银行 A 在更新该记录时获取访问令牌是不自然的Jane Doe，因为这不是调用者身份。在审计层面：

• 授权服务器将指示令牌已发给银行 A
• API 将指示 Jane Doe 的记录由银行 A 更新。

API 可能有许多复杂的域特定规则，围绕允许的数据更新类型。这些通常在 API 逻辑中进行管理，而访问令牌仅包含 API 可以在应用规则之前以数字方式信任的关键调用者身份信息。

有关此主题的更多信息，请参阅我们的索赔最佳实践文章。

Answer 3

介绍

以下答案描述了可用于允许受信任的 OAuth客户端在未经资源所有者access_token事先同意的情况下获得授权的流程、授权和参数。此方法在模拟场景中使用令牌交换授权（在RFC 8693中定义），其中客户端必须伪造不安全的并将其交换为安全的。此方法假定授权服务器生成和使用 JWT ( RFC 7519 )。它不适用于不透明的令牌。subject_tokenaccess_token

序列图

第 1 步：伪造初始 JWT

在第一步中，客户端伪造一个初始的不安全的 JWT 令牌（RFC 7519，第 6 节）。此 JWT 必须至少包含主题 ( sub) 声明，作为值，资源所有者或客户端想要模拟的另一个主题。

第 2 步：客户端请求将初始不安全 JWT 交换为安全访问令牌

客户端将步骤 1 中伪造的 JWT 交换为安全访问令牌。根据RFC 8693 第 2.1 节，客户端发送带有以下标头/参数的令牌交换请求：

• 标Authorization头包含客户端凭据（客户端 ID和客户端密码），遵循基本身份验证方案。
• body 参数grant_type指定我们要使用的授权类型：token_exchange
• body 参数subject_token包含步骤 1 中伪造的 JWT
• body 参数subject_token_type指定我们伪造的主题令牌类型：an access_token（实际上是一个 JWT）

这是客户端必须发送的最低要求。尽管它应该可能指定audience、目标resource服务器和scope.

第三步：授权服务器返回访问令牌

根据其策略，授权服务器将客户端标识为受信任的，因此允许生成一个access_token不安全subject_token的输入。（权利要求）中定义的主题是在生成的.subject_tokensubaccess_token

授权服务器还将根据 RFC 8693 第 4.1 节添加一个Actor声明( act) 。此声明的值是一个 JSON 对象，具有另一个键和客户端 ID作为值。sub

第 4 步：客户端请求资源

在此示例中，客户端使用访问令牌请求“个人”资源( /my/resource) 。JWT 中的声明用于识别“我的”，也就是主题。sub

第 5 步：返回资源并模拟主题

而已。

免责声明

我从未实施或测试过这个解决方案。它显然需要对您的授权服务器及其策略进行一些更改。未执行任何安全审计。小心这个流程。实施前应要求 OAuth 专家的确认。