How Resource Server can identify user from token?

Question

I'm trying to understand how OAuth 2 works. I don't understand this thing: if Authorization Server and Resource Server are not the same system, as in this image:

How the resource server can know who is the user and what are his permissions? Can I retrieve these information from the Access Token or I must have a back-end comunication between Authorization Server and Resource Server?

Answer 1

Access token is usually a randomly generated string, so you cannot read any information out of it (but there may be OAuth2 implementations that use some meaningful values). The resource server must validate the access token and its scopes, not the permissions of the user who was authenticated before creating the token (resource owner). That's an important detail, because OAuth2 is a protocol for permission delegation from a resource owner to a client in form of an access token and its scopes. To do that, the resource server needs to make an HTTP request to the Token Introspection endpoint of the auth server. The JSON response contains

1. Boolean flag active that says whether the access token is still valid (not revokend, not expired)
2. Parameter scope holds its scopes granted by the resource owner
3. username of the resource owner
4. Some other useful fields.

The resource server should check that the access token is active and that it contains scopes required by the requested resource or service. It may perform some other validations (such as the requested resource is owned by the resource owner identified by the username field).

The introspection response for a given access token may be cached by the resource server (to improve performance). See the RFC for security considerations.

Access token may self-contain the authorization information in a verifiable manner (for example signed JWT). In such case, the resource server should be able to verify the authenticity (signature) and scopes of the token without calling the auth server, but then it's hard to implement the token revoke endpoint, since the resource server would accept a token even if it gets revoked at the auth server.

Answer 2

Depends on the type of token as to how it's consumed by the resource server.

Self encoded access tokens tokens (e.g. JWT bearer tokens) will contain all the user and scope information in the token. Or some Auth systems use token introspection as detailed in Jan's answer.

This is a good introduction to the resource server and the types of token.

And a very common self encoded token is the JWT Token.

Taking the example of a self-encoded access token:

The Access Token will contain the user identifier and scopes / permissions for the token issued in the example above - which is the "implicit" grant type.

The Resource server should not need to contact the auth server. This can be one of the key benefits of Oauth 2.0 for APIs. It must trust it though. It should confirm the token has been signed by the auth server, and it may also need to be able to decrypt the token, if encrypted by the auth server.

Obviously the resource server needs to be able to access the data for the user in the token. It may be that the auth server and resource server point to the same underlying database.