问题标签 [rfc6749]

我正在实现 oauth2 授权服务器。

当使用 oauth2 交换刷新令牌来访问令牌（rfc6749）时，我的客户端 - 一个在实现拦截器时遇到问题的移动应用程序（由于多种原因）。

和以前一样，我的客户端执行令牌交换流程（rfc8693）并且访问令牌存储在数据库中，所以我决定返回当前访问令牌（仅当它仍然有效时）而不是每次接收刷新令牌时都发出新的访问令牌。

访问令牌的生命周期很短（大约 5 分钟），用户可以撤销访问令牌和刷新令牌。

但是这个决定是针对 rfc6749 的，它声明了新的访问令牌：

授权服务器对客户端进行身份验证并验证刷新令牌，如果有效，则发出新的访问令牌（以及可选的新刷新令牌）

我想知道这个决定是否会导致任何问题？

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

用例描述

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

调查

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

客户凭证

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，这可能是另一个不错的提议。