如何确认哪些资源每个用户可以通过OAuth和OpenID连接上网？ [英] How to verify which resources each user can access with OAuth and OpenID Connect?

问题描述

假设我们有我们要揭露其暴露的一些资源的RESTful API。最终用户将通过如移动应用和基于JavaScript客户端上的Web浏览器上运行的客户端应用这个API的工作。

使用OAuth 2.0这个API的RESTful会说谎的资源服务器上，我们将不得不在其上客户端应用程序登记注册的授权服务器。用户将随后在授权服务器上注册，并能够将权限授予这些应用程序的访问资源代表他们或没有。

所以，当他将被重定向到授权服务器，并会提示授予权限的用户访问一个客户端应用程序，以表示客户端应用程序。在这之后的访问令牌发放和客户端能够发送请求到资源服务器。

这一切是相当清楚的给我。这里还有一个遗漏的部分：每个资源的保护可能是取决于用户。为了更precise它可能是权利要求依赖性。我的意思是，我们可以有以下情况：

• 资源 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的，我以下列方式处理：当请求是与授权发送：承载[令牌] 头，在服务器端线程主要设置，我认为这意味着用户正在使用API​​认证。所以我用 [授权] 属性，以验证是否用户可以访问的资源。

留学后的OAuth更深刻，我看到这是协议的一个可怕的滥用。正如我了解到，OAuth认证的应用程序和而不是用户。当请求与Authorization头做，因为我已经了解到，访问令牌不应该被允许发出请求包含有关用户的信息，只是应用程序。

考虑到该请求发送授权头无法识别用户，并在用户可以或不可以访问说资源不不说了。

在这种情况下，一个人如何执行这种授权的？我的意思是，未授权的客户端应用程序执行请求的，但用户访问基于他的要求的资源的授权？我相信这是哪里的OpenID Connect和它的ID令牌来了，但我不能确定。一个人如何管理这？

解决方案

这是访问令牌不包含用户的说法，但它包含了谁授予权限的客户端应用程序的用户在主题 。 主题是一个技术术语，它是指一个唯一的标识符。简单地说，主题是在数据库中的用户ID。

在受保护的资源的端点，你会做什么：

1. 从请求中提取访问令牌。 （ RFC 6750 ）


2. 获取有关从授权的服务器对访问令牌的详细信息。 （ RFC 7662 ）


3. 验证访问令牌。确认包括（一）是否访问令牌已过期或没有，和（b）访问令牌是否涵盖范围（权限）由受保护资源的端点必需的。

以上1至3反对的访问控制的步骤客户端应用程序的。 OAuth 2.0用户（ RFC 6749 ）就是这个。请参阅保护资源通过的 Authlete （由我）有关这些步骤的详细信息。

在上面的步骤，那么你会做什么：

<醇开始=4>

从提取访问令牌的主题。再次，受试者是用户的一个唯一的标识符。

从数据库检索用户的要求。

验证索赔，只要你喜欢。

4至6上述步骤是反对的用户访问控制的。 OAuth 2.0用户是不是这个。

的OpenID连接的主要目的是得到一个 ID令牌以可核查的方式。可以确认的ID标记已由权利方发出通过核实附加到该ID的令牌的签名。见JSON网络签名（JWS）（ RFC 7515 ）有关签名的详细信息。

这是ID令牌本身不是保护Web的API的技术。但是你可以用它来此目的，如果你使用 at_hash 要求在一个ID令牌正确（见的 3.1.3.6。ID令牌中的 OpenID的核心连接1.0 ）。然而，在受保护的资源的端点，它会更容易直接从数据库中获取索赔，而不是解析一个ID令牌。

---

^{[其他答案＃1注释]}

在您的使用情况下，你不需要ID令牌。这是因为访问令牌已经包含有关用户的被摄体信息。正常情况下，信息就相当于分索赔在ID令牌的值。

因此​​，你并不需要一个ID令牌来获取用户的主题。见第4步的描述，你可以找到提取在访问令牌的主题。

---

^{[其他答案＃2注释]}

  

那么，有什么不对的提取这样的访问令牌中的主题和核实这些索赔？或者，这是做事的正确方法吗？

有什么不对。例如，假设你定义一个Web API， https://api.example.com/profile ，它返回用户个人资料信息。在正常情况下，这样的API会接受一个访问令牌，然后提取访问令牌的主题确定为参考的用户。另一方面，如果API没有提取的访问令牌的主题，它必须要求主体作为请求参数来确定指哪个用户（或需要的ID标记，它包含分，权利要求） 。即使在这种情况下，API必须检查由请求参数和与所述接入令牌相关联的主体中指定的对象是否是相同的，因为否则它会成为一个安全问题。

检查后索赔提取的主题也是一个正常的步骤。例如，您可能希望限制基于用户已支付（免费计划，精简版的计划，企业计划，或其他）计划为您服务的功能。在这种情况下，你将不得不参考计划索赔。当然，检查这种说法只能提取访问令牌中的主语之后完成的。

因此​​，（1）在受保护资源的端点的实现中提取从接入受试者令牌，然后（2）验证所述用户的权利要求中正常，甚至典型步骤

Suppose we have some RESTful API which whose exposed resources we want to expose. End users will work with this API through client applications like mobile apps and Javascript based clients that run on web browsers.

With OAuth 2.0 this RESTful API will lie on the Resource Server and we will have one Authorization Server on which the client applications are registered. The users will then be registered at the authorization server and will be able to grant permission to those applications access resources on their behalf or not.

So when the user access one client application he will be redirected to the Authorization Server and be prompted to grant permissions to said client app. After that an access token is issued and the client is able to make requests to the Resource Server.

All of this is quite clear to me. There's just one missing piece: the protection of each resource might be user-dependent. To be more precise it might be claims-dependent. What I mean by that is we can have the following situation:

• The resource http://resourceserver.com/api/first-resource should only be accessible to users with claim "ExampleClaim" with value 123.

• The resource http://resourceserver.com/api/second-resource should only be accessible to users with claim "AnotherClaim" with value 123.

• The resource http://resourceserver.com/api/third-resource should be accessible to any users.

When I first heard of OAuth was dealing with ASP.NET WebAPI and I dealt with that in the following way: when the request was sent with the Authorization: Bearer [token] header, on server side the thread principal was set and I thought that this meant the user was authenticated with the API. So I used [Authorize] attributes in order to verify if the user could access the resource.

After studying OAuth more deeply I saw this was a terrible misuse of the protocol. As I've learned, OAuth authorizes applications and not users. When the request is made with the Authorization header, as I've learned, the access token shouldn't contain information about the user, just about the application being allowed to make the request.

Considering that, sending the Authorization header with the request doesn't identify the user and does don't say if the user can or cannot access said resource.

In that case, how does one perform this kind of authorization? I mean, not authorization of the client app performing the request, but the authorization of the user accessing the resource based on his claims? I believe this is where OpenID Connect and it's ID tokens come in, but I'm unsure. How does one manage this?

解决方案

An access token does not contain a user's claims, but it contains the subject of the user who has granted permissions to the client application. "Subject" is a technical term and it means a unique identifier. Simply saying, "subject" is a user ID in your database.

At a protected resource endpoint, you will do:

1. Extract an access token from the request. (RFC 6750)
2. Get detailed information about the access token from the authorization sever. (RFC 7662)
3. Validate the access token. The validation includes (a) whether the access token has expired or not, and (b) whether the access token covers scopes (permissions) that are required by the protected resource endpoint.

The steps above from 1 to 3 are an access control against client applications. OAuth 2.0 (RFC 6749) is for this. See "Protected Resource" by Authlete (by me) for details about these steps.

After the steps above, then you will do:

4. Extract the subject from the access token. Again, "subject" is a unique identifier of the user.
5. Retrieve claims of the user from your database.
6. Validate the claims as you like.

The steps above from 4 to 6 are an access control against users. OAuth 2.0 is NOT for this.

The primary purpose of OpenID Connect is to get an ID token in a verifiable manner. You can confirm that an ID token has been issued by a right party by verifying the signature attached to the ID token. See JSON Web Signature (JWS) (RFC 7515) for details about signature.

An ID token itself is not a technology to protect Web APIs. But you may be able to use it for that purpose if you use at_hash claim in an ID token properly (see "3.1.3.6. ID Token" in OpenID Connect Core 1.0). However, at a protected resource endpoint, it will be much easier to get claims directly from your database than to parse an ID token.

---

^{[ Additional answer #1 for the comment ]}

In your use case, you don't need ID tokens. It's because an access token already contains information about the subject of the user. In normal cases, the information is equivalent to the value of sub claim in an ID token.

Therefore, you don't need an ID token to get the subject of the user. See the description of the step 4, and you can find "extract the subject from the access token."

---

^{[ Additional answer #2 for the comment ]}

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?

There is nothing wrong. For example, suppose you define a Web API, https://api.example.com/profile, which returns profile information of a user. In normal cases, such an API would accept an access token and then extract the subject from the access token to determine which user to refer to. On the other hand, if the API did not extract the subject from the access token, it would have to require "subject" as a request parameter to determine which user to refer to (or require an ID token that contains "sub" claim). Even in such a case, the API must check whether the subject specified by the request parameter and the subject associated with the access token are identical because otherwise it would become a security issue.

Checking claims after extracting the subject is also a normal step. For example, you may want to restrict functionalities of your service based on the plan that the user has paid for (Free plan, Lite plan, Enterprise plan, or whatever). In this case, you would have to refer to plan claim. Of course, checking such a claim can be done only after extracting the subject from the access token.

Therefore, (1) extracting the subject from an access token and then (2) verifying the claims of the user are normal and even typical steps in implementations of protected resource endpoints.

这篇关于如何确认哪些资源每个用户可以通过OAuth和OpenID连接上网？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！