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。

例如，它可以像这样工作 - 每当您的资源服务器获得一个没有 notifications:read 范围的令牌时，在日期 x 之前发布（所以在您发布该范围之前）它执行与授权服务器的交换并且（如果服务器决定它可以执行交换）它获得一个包含该范围的新访问令牌。如果令牌是在日期 x 之后颁发的，您可以放心地假定令牌没有被授予此范围。

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

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