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?

Holmquist

Answer 1

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.

Kaon

I am not sure your statement is right. The Resource server should not need to contact the auth server? This indicates that there is a POST request. Do I misunderstand something? – Medicare

Answer 2

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.

Monney

I think that this one should be the answer. – Medicare

Answer 3

It can be complicated. There are many different implementations and combinations relationships between the User, Application and Resources.

Perhaps a more descriptive explanation of your architecture and relationships between the entities involved would be helpful.

If you are trying identify the User, then OAuth is not the correct protocol. YOu should look into OpenID Connect or User-Managed Access.

Generally the Resource server would only need to know the scopes to be able to provide access. Not the Identity of the user.

-jim

Kilowatthour

Answer 4

From my point of view, the Auth Server and the App Server must agree before starting work.

The App Server registers with the Auth Server and fills some form registration on the Auth Server and sends it something like AppServerId. The Auth Server sends it a SecretKey (or multiple SecretKeys depending user roles) instead (using RSA for example) and saves it in its own dictionary [AppServerId:SecretKey].

When we start working with the API and the App Server gets the JWT, it already has SecretKey and can verify it. It can also get some additional info from the JWT like user_id, etc.

Moreover, that is just one of the ways we can realize JWT validation.

Depending on developer desire and system needs, we can periodically ask the Auth Server to get a new SecretKey or get a SecretKey for each user separately (it can only be done after the first API call to the App Server) and then cache it.

Morphology