How can a OAuth2 resource server relate an access token to the user that authorized it to prevent unauthorized access to other user resources?

Question

I'd appreciate if someone could clear up if, according to the OAuth2 RFC, the resource server could infer the user associated to an access token or not, or even if that is expected.

Let’s assume the following:

• The authorization server and the resource server are separated and independent.
• The client is a printing service.
• The resource server hosts user photos.
• The client wants to invoke a protected API from the resource server to get user's photos https://es/api/users/USER_ID/photos and print them.
• The client redirects the user to the independent authorization server and ends up generating an access token.
• The client uses that access token to get and print some user photos.

Since the token is opaque and has no meaning to the independent resource server nor the client, nothing would prevent the client from using that access token to access and print photos from any user, not only the one who authorized it.

Is this right? Or otherwise, how does the resource server relate the user to the token to limit its usage?

Answer 1

You can implement OAuth 2.0 Token Introspection as a way for resource server to query authorization server for token metadata.

Using defined introspection response fields you could transport Resource Owner identity in sub and username fields.

Moreover I would say that if the token is really opaque then you not only may but should implement introspection because it is a way to check.

• If the token is really issued by the right authorization server - you can ensure that also by cryptography but not the later things
• If the token is still active
• If the token was issued to the client using it
• If the scope of the token covers the requested operation

Answer 2

oAuth 2.0 does not have a build in mechanism to do this, however there are a few scheme's you could employ to make this work.

1. use an Authentication layer on top off oAuth (like openID Connect) to retrieve the user information you need

2. Add a scope per user details to access said user details and only grant that scope for that user. Just be aware of the information leaks that can cause.

3. Use the Authorization provider as gatekeeper and have it provide the requested details for that specific user not the resource server where the pictures are actually being stored. sort of a cop out but would also work.

Answer 3

OAuth deals with authorization: the token only gives an indication of the permissions delegated. It might also have information about the user who delegated permission but it doesn't actually represent a user. It is up to the resource server to make sense of the permissions and limit usage accordingly.

If due to nature of your servers this is not possible to set without the identity of the user then you will require authentication solutions that work along with OAuth (e.g. OpenID Connect).

Answer 4

The authorization is carried with the implementation of redirection which preserves the authenticity of the application server and authorization server.

OAuth supports different types of workflows. The Authorization Code Grant type is the most commonly used since it is optimized to take advantage of the redirect capabilities of a web browser.

More info can be found with the following resource:-

https://revs.runtime-revolution.com/an-in-depth-look-at-the-oauth2-redirect-flow-8a5e6c964085