我非常清楚OAuth2令牌交换流和角色。我不清楚的是它如何映射现实世界的场景。如果我的网站像GUI部分（客户端）那样与后端休息API（资源提供者）通信，它会从Auth服务器请求令牌以对RP进行身份验证。令牌通常携带描述用户的权限或角色，因为它们将由RP强制执行。但是，GUI通常需要根据授予令牌的范围/角色来做出决策。一方面看起来它应该反省令牌以找出这些信息以“适应”UI以匹配用户的权限。另一方面，令牌不需要是可读的，它们可能是不透明的。似乎授权决策是在客户端和客户端完成的。 RP，这似乎表明客户端也是次要RP？ GUI用于接收用户授予其访问权限的角色/范围的预期模式是什么？
答案 0 :(得分：0)
您是在谈论OAuth2.0还是OIDC或两者兼而有之？您已标记openid，因此我会假设两者。
似乎授权决策正在客户端和 RP
OAuth2.0客户端是OIDC依赖方。他们是一回事。
如果您正在使用混合拨款 - 即您使用OAuth2.0和OIDC来获取access_token和id_token，那么您的id_token将包含您的客户（信赖方）的信息） 可以使用。它是一个JWT令牌，具有您可以信赖的信息格式。它也是透明的。
另一方面，access_token可能是不透明的，也可能不是 - 无论是您的客户端传递到您的资源服务器而不是尝试使用自己。
access_token应包含与您的客户端可以在资源服务器上访问的内容相关的范围（您的后端其余API），而您的id_token应包含与用户是谁，何时以及如何相关的声明他通过身份提供商/授权服务器提供身份验证和任何其他身份声明。这些声明可能允许您的客户根据需要定制GUI。