Is it "allowed" to modify the scope of the token in the database once it has been created?

[jahrralf]

Scenario: I have an app working with a PHP backend. When the user logs in, I can only check a receipt of an in-app purchase which has already been uploaded to the server to see "if he/she is premium" or not. If I see that the subscription in the receipt has expired I need to get a newer one. This should happen as infrequently as possible as the user always has to re-enter his itunes password (on iOS) so that I can get the receipt.

My plan would be:

• Log in, create the OAuth2 token (Bearer, stored in the database). Check if there is a receipt. If yes, check if it has an expired subscription. In this case add scope SUBSCRIPTION_EXPIRED. In some other cases, if things work well, add scope PREMIUM.
• If client finds out via backend that he has scope SUBSCRIPTION_EXPIRED, he gets a newer version of the receipt and uploads it.
• The server now checks the new receipt and should/could remove scope SUBSCRIPTION_EXPIRED and replace it by nothing or PREMIUM, whatever the result of the check of the receipt gives me. At that point, the access_token is already known to the client and stored there.
• Any further requests to the server with given access token would use the scope; upon a new login I would use the new receipt and should be able to immediately decide.

[bshaffer]

There isn't a precedent in the spec to modify scopes one issued. There is only the concept of downgrading scopes, e.g. if you have a refresh token with scope "thing1, thing2", you can use that to get an access token with only scope "thing1" or only scope "thing2".

There's a better way to accomplish what you want. For instance, if your access token is tied to a user, check the user for the subscription status.