How should resource providers validate OAuth2 tokens?

Question

Resource providers often provide read and write access to resources.

A resource provider should therefore not only validate the token (is it expired? is it revoked? is it valid? does it contain the required scope?), they should also check the token's privileges (does use XY have sufficient privileges for reading or writing resource ZY?).

Until now I have used the following workflow:

1. Client receives an access token through the OAuth2 code grant.
2. Client makes a request on behalf of the user to e.g. GET /user_postings
3. The Resource Service (let's call it User Postings) validates the token by making a request to the Authorization Server, confirming that the token is valid. The Authorization Server additionally passes metadata like the token expiration date, the token's audience, the token's scopes and the token's subject (e.g. User XY)
4. The Resource Service now validates that the subject (e.g. User XY) is authorized / allowed to perform the request. For example by checking an Access Control List or similar. For Example: Let's say User XY wants to update a user posting by User AB. This would for example be dis-allowed by the Access Control List.
5. If validation passes, the Resource Server executes the request.

Is this a valid way of doing things or am I opening up attack vectors? Is it ok for the Resource Server to assume that the token's subject is the one to be considered the authorization request? Are there maybe best practices or standards for solving this?

I am currently confused, because I read OAuth2 is delegation only, not authorization nor authentication and that clients should not make implicit assumptions like "token XY belongs to user AB, so user AB is authenticated".

Any help is gladly appreciated.

Answer 1

RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage , Section 5: Security Considerations discusses some of the issues related to the use of bearer tokens. From section 5.2:

5.2. Threat Mitigation

A large range of threats can be mitigated by protecting the contents of the token by using a digital signature or a Message Authentication Code (MAC). Alternatively, a bearer token can contain a reference to authorization information, rather than encoding the information directly. Such references MUST be infeasible for an attacker to guess; using a reference may require an extra interaction between a server and the token issuer to resolve the reference to the authorization information. The mechanics of such an interaction are not defined by this specification.

In step 3 of your workflow you describe the resource service asking the authorization service if the token is valid. This is an example of using a reference to resolve authorization information. However, step 4 has the resource server validating the subject (e.g. UserXY). This is an example of encoding authorization into the token itself. This hybrid approach isn't a problem but you could simplify your design by picking one or the other.

Also, instead of using a token subject UserXY to impart all a user's authorizations to a single token, it may be better to use the principle of least privilege here and have the authorization server put specific authorizations (e.g., read UserXY email, compose UserXY messages) rather than giving access to anything UserXY can do.