使用身份验证令牌授予对特定项目的访问权限答案

【问题标题】：Using Auth Tokens to grant access to a specific item使用身份验证令牌授予对特定项目的访问权限
【发布时间】：2021-03-11 01:19:52
【问题描述】：

我有一个应用程序，它为经过身份验证的用户提供有关数据库中各种对象的数据的视图。在我们的生态系统中还有另一个应用程序，它使用自己的权限模型为某些相同的对象提供不同的视图。我们信任其他应用程序的权限模型，并希望允许他们向尚未通过我们应用程序通常方法进行身份验证的用户颁发访问令牌，因此这些用户只能查看其他应用程序已验证他们有权访问的特定对象.

与其为这两个应用程序之间的通信制定我们自己的规范，我想知道是否已经有一个标准方法可以通过诸如 OpenID Connect 之类的方式使用。 OIDC 似乎处理了我们在这种情况下必须考虑的大部分细节，但它似乎不适合的一个方面是它的访问令牌似乎是通用的，而不是调用一个用户有权访问的特定对象。它说“这是一个可以访问您的应用程序的用户”，而不是“这是一个可以访问项目 123 的用户”。

是否有使用访问令牌授予对特定项目的访问权限的标准，最好使用 OAuth 2 和/或 OpenID Connect？我是否正确假设在访问令牌上使用项目的 ID 作为 scope 会不恰当地使用 OAuth 范围？

【问题讨论】：

在我的阅读中，我发现scope 不是持有用户许可的好人选：应用程序需要拥有的范围are for specifying which groups of claims。但是sounds like 可以将数据包含在namespaced Custom Claims 中。

标签： oauth-2.0 openid-connect

【解决方案1】：

我一直认为大多数现实世界应用的最佳设计是这样的：

基于 OAuth 2.0 的技术可识别用户
然后您在应用程序级别查找用户详细信息以强制执行授权

OAuth 2.0 范围等无法处理这样的事情：

您无权访问帐户 123
您无权访问美国地区

所以我倾向于在登录后从令牌中的用户 ID 查找它们。这也往往更容易扩展，例如，如果外部应用程序中的项目和用户权限随着时间的推移而增长。

有关更多具体信息，请参阅我在 API Claims Caching 上的文章。

Rest API 中编码算法的 here is an example 也是，导致声明对象可以是 injected into logic classes。

在您的情况下，自定义声明提供程序将是外部应用程序，您可以从中查询声明，以获取不太适合 OAuth 令牌的数据。

只是我的想法 - 不确定它是否完全适合你 - 但我发现这是一个适应性很强的解决方案，它通常将责任放在正确的地方。

【讨论】：

这也是我通常采用的方法。这是我们的应用程序到目前为止所采用的方法。在这种情况下，用户是否被授权的事实来源是一个单独的应用程序。该应用程序实际上有一组单独的用户不会被认证为我们应用程序的普通用户，我们的正常授权规则也不适用于他们。对于这个单独的用户组可以访问的功能子集，我们需要他们有一个令牌来证明他们被允许使用该应用程序。
理论上，我们可以使用该令牌在每个请求中查询该应用程序，并让该应用程序响应有关该应用程序的授权规则是否允许它们查看给定资源的信息。但是让令牌本身包含足够的授权信息来避免那些额外的往返行程是有好处的。
有趣的场景。我想我的目标是通过声明缓存设计来处理它，在这种设计中，您的后端 API 向其他应用程序询问规则 - 但仅在首次收到令牌时 - 以确保良好的性能。它类似于 API 网关如何进行自省请求，并且也易于扩展。我已经编辑了上面的答案以指向几个链接。