I’m having some troubles understanding how OAUTH-v2 works.
The OAuth version 2 spec reads:
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.