In that case the game is the client as it is using the access token to get to the protected resource (FB graph API in this case). The resource owner can revoke a granted scope at the authorization server after the fact. That is how Facebook works now, as near as I can tell.
Not that Facebook is a good example of how OAuth should work, They issue long lived access tokens and not refresh tokens. A well behaved Authorization server would grant a refresh tokens with all of the granted scopes, once the short lived access token expires it would get a new one and see that it had been downs coped from the original grant scope set. The correct design is using a refresh token. that way if the user has edited the scopes on the way to the Authorization server the client just needs to use the refresh token with the scopes it believes were granted. If it gets back a downs coped response it knows something has changed. I have a hard time being sympathetic, because OAuth was not intended to enforce service agreements on behalf of the Client, it is acting on behalf of the resource owner. Enforcing multiparty service agreements should be a OAuth extension for those that want it. John B. On 2012-02-23, at 10:12 PM, Nicholas Devenish wrote: > > On 24 Feb 2012, at 01:02, Wenjie Lin wrote: > >> As we have shown in our Feb 17th email, the negative consequence is a >> violation by the user of the service agreement, that is, the user is able to >> play the game but the client cannot post messages on behalf of the user. > > That's not a negative within the context of the OAuth protocol, which > protects the users interests, not the clients. It looks as though with the > current wording, it's basically not possible to be compliant (very mildly) in > this scenario. > > But as John Bradley pointed out, it's completely legitimate for a client to > give the "game" full permissions, and then edit the scope afterwards (though > I can't find an explicit reference in the draft, I expect it to be covered by > one of the "This is out of scope" or revocation clauses). > > Implementations that want to allow clients to enforce the scope contract with > the user could always just implement a method to get the actual scope back > (like facebook), but it's not an attack against the protocol or user.. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
