Rest 具有预配置授权的OAuth安全性

我有一个场景，用户登录到web应用程序（使用OpenID Connect进行身份验证），然后需要从单独的REST服务访问数据

REST服务需要确定用户是否具有访问请求数据的权限，但是如果用户确实具有权限，则它应该向web应用程序授予授权，而不需要用户与UI交互

本质上，我需要的是一个两条腿的OAuth解决方案，其中客户端/依赖方是完全可信的，但是已经通过身份验证的用户不是

我假设OAuth可以满足这些需求，但没有一种赠款类型符合这些需求：

• 授权码与我需要的恰恰相反，因为用户几乎是自动受信任的，但客户端不是，要求用户通过web表单授予对客户端的访问权限
• 客户端凭据信任客户端（这正是我所需要的），但不给服务机会来确定用户是否具有资源权限（用户身份验证令牌不会传递给服务，使所有请求基本上都是“匿名的”）
• ROPC（资源所有者密码凭据）似乎是唯一的选项，但需要web应用程序知道并可能存储用户的登录凭据（这是不成立的）

这是OAuth中的一个缺口吗？还是我误解了这些补助金类型？如果OAuth不能支持这个场景，那么我是否错过了另一个被广泛采用的开放标准

---

注意：我只拥有/控制web应用程序，而客户（都是企业）同时拥有/控制身份验证服务器和REST服务。因此，一个共享的、非专有的标准是必要的，这样我们的客户就可以知道如何配置他们的服务（IBM、Microsoft等等），这样我就可以知道如何传递任何身份验证令牌等等。

我认为使用普通的OAuth2流可以做到这一点。您让您的web应用程序使用获取令牌以代表用户调用API

web应用程序调用API，将JWT令牌附加到授权头中。如果REST服务确定用户没有访问资源的权限，它将返回401个未经授权的HTTP响应代码

web应用程序通过返回授权服务器并使用获取访问令牌来代表客户端本身调用RESTAPI来处理401响应

---

由于这两种授权都允许您获取刷新令牌，因此您应该能够轻松地在访问令牌之间切换。

如果web应用程序和REST服务之间没有信任关系，使用授权码授权是没有办法的，因为用户无论如何都需要参与，以允许web应用程序代表用户进行调用

如果web应用程序和REST服务之间存在信任关系，您应该能够使用常规OpenID连接流在登录时获取web应用程序的访问令牌，该令牌也可以用于对REST服务的调用

---

您可以将用户信息作为由web应用程序本身或OP签名的JWT（即结构化）访问令牌的一部分进行传递；这将符合OAuth2.0。请参见和。

您能否勾画出相关各方的互动图？。我想我明白了您的意图，但无法完全确定。>“REST服务需要确定用户是否有权访问请求的数据，但如果用户确实有权限，则应向web应用程序授予授权，而无需用户与UI交互。”如果是这种情况，那么为什么不总是使用客户端凭据访问API呢？为什么首先要检查用户是否有访问权限？如果我理解正确，使用授权代码，客户端不会向授权服务器发送任何类型的客户端ID/密码。我想预先授权客户机，这样用户就不需要显式地授予客户机代表他们访问服务的权限。可能吗？（需要使用现有标准-标准的自定义扩展将由于各种原因导致许多问题。）使用授权代码，客户端也会发送自己的凭据。但是令牌是代表用户调用您的服务。您始终可以使用客户机凭据授权事先为客户机获取令牌。这行得通吗？如何在web应用程序和REST服务之间建立信任关系？是否有标准方法将用户的身份验证令牌转发给REST服务，以便验证其访问资源的权限？您可以将用户信息作为由web应用程序本身或OP签名的JWT（即结构化）访问令牌的一部分进行传递；这将是OAuth 2.0合规性。您可以用该建议更新您的帖子，并指向一些权威参考资料吗？在奖金到期之前，我没有足够的时间验证您建议的方法，因此我将根据我对该解决方案潜力的看法授予它。如果真的有效，我会回来接受答案。