OAuth v2 communication between authentication and resource server

I'm having some troubles understanding how OAUTH-v2 works.

The OAuth version 2 spec reads:

> 7. Accessing Protected Resources > > > The client accesses protected > resources by presenting the access
> token to the resource server. The > resource server MUST validate the
> access token and ensure it has not > expired and that its scope covers
> the requested resource. The methods > used by the resource server to
> validate the access token (as well as > any error responses) are beyond the > scope of this specification, but > generally involve an interaction or > coordination between the resource > server and the authorization
> server.

How does this interaction between resource server and authorization server work in practice?

• How does the resource server determine that an access token it received is valid?
• How does the resource server extract the allowed scope from the token to see if access should be granted to a particular resource? Is the Scope encoded in the access token, or does the resource server first have to contact the authorization server?
• How is trust between the resource server and the authorization server established?

> Access token attributes and the > methods used to access protected > resources are beyond the scope of this > specification and are defined by > companion specifications.

Can someone give examples for token attributes?

The reason this is out of scope for the specification is the wide range of ways to accomplish this connection between the two entities. The main question is how complex is your deployment.

For example, do you have one server managing authentication and access, and a set of discrete services each with its own servers serving the API calls? Or, do you have just one box with one web server which handles both authentication/authorization and the API calls?

In the case of a single box, not much is needed as the entity issuing tokens is the same as the one validating them. You can implement tokens to use a database table key and lookup the record in the database (or memory cache) on every request, or you can encode the scope, user id and other information directly into the token and encrypt it using a symmetric or asymmetric algorithm.

Things get a bit more complex when dealing with a distributed environment, but not by much. You still issue tokens at the authorization server, but the resource server needs a way to validate those. It can do it by making an internal API available to the resource server to ask the authorization server to "resolve" the token (which can be fast in a local environment), or the two can establish a public/private key pair or symmetric secret and use that to encrypt everything the resource server needs into the token.

Self contained tokens are longer but offer much better performance per-request. However, they come with a price - you can't really revoke them while they are still valid (not expired). For this reason, self contained tokens should be very short lived (whatever is acceptable to you to leave access open after it was revoked - e.g. many sites use one hour), with a refresh token good for a year or more to get new tokens.

One example of resource- to authorization server API is the one at [Google Developers Website][1].
It doesn't specify the format of the access token though, but the response seems pretty universally useful.

[1]: https://developers.google.com/identity/protocols/OpenIDConnect?csw=1#validatinganidtoken "Using OAuth 2.0 for Login"