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:
- Client receives an access token through the OAuth2 code grant.
- Client makes a request on behalf of the user to e.g.
- 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)
- 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.
- 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.