Best practices for handling access tokens and scopes for OAuth2 implementation?

Question

Assume we have an OAuth2 implementation that supports "read" and "write" scope.

I retrieve an access token "f482c829" with "read" scope. If I then change my mind and now want read+write permission and authorize again with "read" and "write" scope do you:

• Update scopes for existing access token and return same token "f482c829"?
• If using same token, require that the access token is reclaimed if using response_type=code before updating scopes? (I think yes)
• Update scopes for existing access token and return a refreshed token "zf382nL"?
• Create an entirely new token leaving "f482c829" and its scopes intact?

If you create a new token every time per scope, you end up having to store multiple access tokens per authorization and different permissions everywhere. I've been hesitant to implement it that way.

The OAuth2 spec (as of draft-12) unfortunately does not address any of this.

Answer 1

In facebook's case, resource server is basically same with authorization server. So they do "use existing token" way. And it enable to allow users to disable each scopes on facebook.com site. About refresh token, you don't need to establish new refresh token. (Of course you can do it though.) Existing refresh token will also be connected with all scopes.

In Google's case (maybe Yahoo! too), resource server is totally different from authorization server. Many resource server (Docs, Buzz etc) accept access tokens established single authorization server. In this case, "establish new token" way seems better.

In Twitter's case (maybe your case too), both seems OK.

Plus, in any way, when user revoked client access you need to revoke all tokens for the client. User is not revoking "token" but "client".

Since developer should pre-register redirect_uri, using same client credentials both on website and on mobile all seems tricky. So I recommend asking developers to use different client credentials in that case.