api - 如何验证每个用户可以使用 OAuth 和 OpenID Connect 访问哪些资源？

Question

假设我们有一些 RESTful API，我们想要公开其资源。最终用户将通过客户端应用程序(如在 Web 浏览器上运行的移动应用程序和基于 Javascript 的客户端)使用此 API。

使用 OAuth 2.0，此 RESTful API 将位于资源服务器上，我们将拥有一个授权服务器，客户端应用程序在该授权服务器上注册。然后，用户将在授权服务器上注册，并且能够代表他们授予这些应用程序访问资源的权限，也可以不代表他们访问资源。

因此，当用户访问一个客户端应用程序时，他将被重定向到授权服务器并被提示授予该客户端应用程序的权限。之后颁发访问 token 并且客户端能够向资源服务器发出请求。

这一切我都很清楚。只有一个缺失的部分:每个资源的保护可能取决于用户。更准确地说，它可能取决于 claim 。我的意思是我们可以有以下情况:

资源 http://resourceserver.com/api/first-resource只有声明为“ExampleClaim”且值为 123 的用户才能访问。

资源 http://resourceserver.com/api/second-resource只有声明为“AnotherClaim”且值为 123 的用户才能访问。

资源 http://resourceserver.com/api/third-resource任何用户都应该可以访问。

当我第一次听说 OAuth 正在处理 ASP.NET WebAPI 时，我是这样处理的:当使用 Authorization: Bearer [token] 发送请求时 header ，在服务器端设置了线程主体，我认为这意味着用户已通过 API 进行身份验证。所以我用了 [Authorize]属性以验证用户是否可以访问资源。

在更深入地研究了 OAuth 之后，我发现这是对协议(protocol)的严重滥用。据我所知，OAuth 授权应用程序而不是用户。据我所知，当使用 Authorization header 发出请求时，访问 token 不应包含有关用户的信息，而应包含有关允许应用程序发出请求的信息。

考虑到这一点，在请求中发送 Authorization header 不会识别用户，也不会说明用户是否可以访问所述资源。

在那种情况下，如何执行这种授权？我的意思是，不是授权执行请求的客户端应用程序，而是授权用户根据他的声明访问资源？我相信这就是 OpenID Connect 及其 ID token 的用武之地，但我不确定。如何管理这个？

Answer 1

访问 token 不包含用户的声明，但它包含 主题 授予客户端应用程序权限的用户。 “主题”是一个技术术语，它意味着一个唯一的标识符。简单地说，“主题”是您数据库中的用户 ID。
在 protected 资源端点，您将执行以下操作:

从请求中提取访问 token 。 ( RFC 6750 )

从授权服务器获取有关访问 token 的详细信息。 ( RFC 7662 )

验证访问 token 。验证包括 (a) 访问 token 是否已过期，以及 (b) 访问 token 是否涵盖 protected 资源端点所需的范围(权限)。

上面从 1 到 3 的步骤是针对客户端应用程序的访问控制。 OAuth 2.0 ( RFC 6749 ) 就是为此而设计的。参见 Protected Resource 的“ Authlete” (由我)了解有关这些步骤的详细信息。
完成上述步骤后，您将执行以下操作:

从访问 token 中提取主题。同样，“主题”是用户的唯一标识符。

从您的数据库中检索用户的声明。

根据需要验证声明。

上面从 4 到 6 的步骤是针对用户的访问控制。 OAuth 2.0 不适用于此。
OpenID Connect的主要目的|是得到一个 ID token以可验证的方式。您可以通过验证附加到 ID token 的签名来确认 ID token 已由正确的一方颁发。有关签名的详细信息，请参阅 JSON Web 签名 (JWS) ( RFC 7515)。
ID token 本身并不是保护 Web API 的技术。但是，如果您使用 at_hash，则可以将其用于此目的。正确声明 ID token (参见 3.1.3.6. ID Token 中的“ OpenID Connect Core 1.0”)。但是，在 protected 资源端点上，直接从数据库中获取声明比解析 ID token 要容易得多。

**[评论的附加答案#1]**
在您的用例中，您不需要 ID token 。这是因为访问 token 已经包含有关用户主题的信息。在正常情况下，该信息相当于 sub 的值。在 ID token 中声明。

因此，您不需要 ID token 来获取用户的主题。参见第4步的说明，可以找到“从 访问 token 中提取主题”。

**[评论的附加答案#2]**

So is there anything wrong in extracting the subject from the access token like that and verify the claims? Or this is the right way of doing things?

没有任何错误。例如，假设您定义了一个 Web API， https://api.example.com/profile ，它返回用户的个人资料信息。在正常情况下，这样的 API 会接受访问 token ，然后从访问 token 中提取主题以确定要引用的用户。另一方面，如果 API 没有从访问 token 中提取主题，则必须要求“主题”作为请求参数来确定要引用哪个用户(或要求包含“子”声明的 ID token ) .即使在这种情况下，API 也必须检查请求参数指定的主题和访问 token 关联的主题是否相同，否则将成为安全问题。
提取主题后检查 claim 也是一个正常的步骤。例如，您可能希望根据用户支付的计划(免费计划、轻量计划、企业计划或其他)来限制服务的功能。在这种情况下，您必须引用 plan宣称。当然，只有在从访问 token 中提取主题之后才能检查此类声明。
因此，(1)从访问 token 中提取主题，然后(2)验证用户的声明是正常的，甚至是 protected 资源端点实现中的典型步骤。