OIDC广义范围

Question

目前正在使用OIDC构建一个微服务来处理与身份验证相关的内容。现在，我们考虑访问控制以及如何尽可能地面向未来。此身份验证服务器仅用于第一方应用程序(3x SPA、2x本机移动应用程序)。在移动端，我们使用authorization_code授权。每个资源服务器自己验证所提供的令牌(访问令牌为JWT)。但是，当(将来)我们添加一个需要自己的作用域进行检查的服务时(例如通知:读取)，会发生什么呢？由于移动应用程序用户不习惯每次登录和注销(当我们通过应用程序更新->更新请求的作用域时)，有没有什么好的解决方案来管理这种情况？

根据规范，可以在刷新令牌时更改所需的作用域，但这仅限于需要比最初请求的作用域更少的作用域，而不是更多，因此这不是一个选项。

例如，Facebook只为Instagram提供了四个作用域，例如instagram_basic或instagram_content_publish。例如，Zalando在他们的令牌中只包含一个作用域NORMAL_USER，而Wolt则包含用户的roles作为声明。

我认为有一些混乱，因为OAuth2或OIDC没有直接涵盖这种情况。你对此有何感想？

Answer 1

做OAuth 2.0 Incremental Authorization只有一个标准，但您的挑战是找到一个支持它或类似标准的令牌提供商。

在微服务体系结构中，问题是您是否应该在任何地方使用来自授权代码流的访问令牌，或者对于服务到服务通信，您应该使用客户端凭据流。

另请参阅https://www.gmass.co/blog/oauth-incremental-authorization-is-useless/

Answer 2

看起来你可以使用Token Exchange来做这件事。

例如，它的工作原理是这样的:只要您的资源服务器获得一个在日期x(因此在您发布该作用域之前)之前颁发的没有notifications:read作用域的令牌，它就会执行与授权服务器的交换，并且(如果服务器决定它可以执行该交换)它就会获得一个包含该作用域的新访问令牌。如果令牌是在日期x之后颁发的，那么您可以放心地假定令牌未被授予此作用域。

另一种解决方案是使用声明进行授权决策，而不是使用作用域。授权服务器可以发出例如声明notifications_read: true或类似的东西。每当您刷新令牌时，您可以在新的访问令牌中发出更多声明，规范不会阻止这一点。然后您的资源服务器应该检查访问令牌中的声明，它们可以忽略作用域。资源服务器将只检查令牌是否包含值为true的notifications_read声明。如果您要求用户同意作用域，这个解决方案就会变得有点复杂，但正如您所说的，您只对第一方使用此解决方案，所以我假设您没有使用同意屏幕。

您可以查看this free course -在第4部分中介绍了在授权中使用声明的主题。