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

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开发者_JAVA技巧 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.

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.

Say one client (mobile) of an application needs read-only access and another client (website) needs to write as well. This would require client to be able to decide the scope of token request and hence provider to store multiple tokens with different scopes.

However, it is up to you if you want to extend the scope of an existing token. This means you can keep one scope per application. This can also make easy to revoke access of an application by a user.