Does an OAuth Consumer validate a bearer token with the OAuth provider on each request

Question

To learn more about OAuth, I'm trying to write an OAuth 2.0 provider and also a consumer.

I'm kind of using the Doorkeeper Gem as a reference for my provider, but I'd like to write my own.

My question is about the last bullet in Section 1.3 of the spec regarding bearer tokens.

(F) The resource server validates the access token, and if valid, serves the request.

In this scenario, does The resource server validates the access token mean that it:

• checks the access token against its own locally stored copy of the access token and its expiry
• makes a request to the provider server, which returns a response of valid/not valid?
• does something else entirely

Answer 1

The specification does not answer that question, because it is an implementation detail that has no effect on the working of the protocol. Nevertheless, it is a good question that can have an impact on security.

First of all, you have to realize that in some implementations, the resource server and the authorization server are just two roles of one single entity.

As the OAuth 2.0 specification (RFC 6749) puts it:

The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity.

They may both be present in a single web site. Maybe they are two different web sites, but they both do have a connection to the same database. The resource server can then lookup the token in the database, just as well as the authorization server can.

If the resource server cannot read the authorization server's database, than it has to talk to the authorization server (and even if it can, it would probably be a good idea to not read the database directly).

How exactly you establish and secure that communication is up to you, but an HTTPS REST request makes a lot of sense. Many implementation have different mechanisms. For examples, see OAuth-2.0 resource servers token validation in distributed environment.

UPDATE: the standard way for a resource server to validate a token is now OAuth 2.0 Token Introspection (RFC 7662).

Obviously, when an access token is presented to a resource server for the first time, the resource server does not know about it, and has to access the authorization server to check for validity. The interesting question now is: can the resource server cache this response, or does it have to make the call on every request?

That is a design decision to be made by the resource server, and it may be influenced by many different factors. For example:

• If the authorization server responds very quickly, there may be no need for the resource server to cache the response. In fact, a badly designed cache may be slower than not caching.
• The need to design and implement a cache with a good cache policy may be prohibitive for implementing a good cache in the resource server.
• Depending on the nature and the scale of the resource server, the cost of allocating RAM or storage on disk to a cache may be prohibitive for implementing a good cache in the resource server. This is especially true when the number of access tokens out there is very high, and a lot of storage is required to obtain a sensible cache hit ratio.
• Is the resource server prepared to accept an access token, even if it has been revoked in the authorization server?

That last point deserves some further explanation. The authorization server typically has several mechanisms to revoke tokens. If a resource owner revokes an authorization through the UI, the authorization server has to invalidate all tokens obtained through that authorization (access tokens and refresh tokens). The resource server may also implement a token revoke endpoint (often used for a "log-out" mechanism in public clients that use the implicit grant).

Is the resource server prepared to take the risk of accepting a token, even after it has been revoked? And if so, for how long? If it is, then it can cache the token, otherwise it can not. At first sight, you would of course say that a resource server SHOULD NOT use cached token validation responses. But in some cases there might be performance advantages that outweigh the risk. It obviously also depends on the nature of the resources stored by the resource server, and the real risks associated with them.

Again, this is a design decision we can not make for you. From a security perspective, you should not cache validation responses in the resource server.