How does an OAuth2 (Bearer) token translate to an ACL

Question

I have been looking into OAuth2 lately and I think I understand the authorization process.

However, what I don't seem to understand is, once authorization has taken place and an access_token and a refresh_token have been established to make calls, how is the decision made based on the access_token if the request can or cannot access a specific resource?

I.e. a token is send to the server to request a photo. How does the logic on the server determines, based on the given token, that access to that particular photo is allowed or denied?

Answer 1

The access_token is usually an opaque artifact. There's nothing intrinsic that associates it with a resource (e.g. a specific photo). When the authorization flow starts, you typically request a specific scope that defines the access you need. If the owner of the resource consents to this access, then the request succeeds. Users can revoke access too.

All this is app specific code. Each app defines what their scopes are and how they enforce the check.

You might want to explore Authorization Server as an example.

Answer 2

The access token is actually an encrypted object, this object defines the scopes and may re-establish the authorization.

Imagine the service provider giving you an HMAC encrypted token which makes no sense to you, but the endpoint knows how to decrypt it. On decryption, it would have info like :

{"scope":"Photos", "userID":"3refefe"}

So, basically the module handling over the token to you encrypts this JSON (or any other format) object and gives you the encrypted token. When you hit the API endpoint, it sends token to the decryption logic and fetches this JSON object and hence knows what all you are authorized to do.

This object can contain any type of info and in any format depending upon the service provider. I have described how an OAuth provider works here.

This should explain the basics of a minimalist OAuth framework.