This site uses cookies to deliver our services and to show you relevant ads and job listings.
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms.

Join us in building a kind, collaborative learning community via our updated
Code of Conduct.

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.

2 Answers
2

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.

Is it true that if the entity issuing and validating tokens has no static white/public IP then service provider callbacks to client/resource owner can't be done through HTTP(s) thus requiring some more elaborate implementations?
– Denys S.Aug 2 '11 at 23:37

Callbacks are not performed by the service provider but by the user's browser. Not sure exactly what you are asking.
– Eran HammerAug 3 '11 at 5:30

What happens if you add some apis that resource server uses( the apis belonging to you ) .Should you then use oath2 authentication (client_credentials) establishing a safe machine-to-machine communication with the resource server ? In that case does that mean that all apis have to share the same key pair with the auth server ?
– Dionisis KJul 30 at 13:44

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