Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

[Nicholas Devenish <[e-mail]>]

On 21 Feb 2012, at 21:59, John Bradley wrote:
> This 'attack'  is one that only works with badly designed clients that are making unwarranted assumptions about the behaviour of the Authorization server.  

Unwarranted assumptions? The spec in 3.3 says:

"If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted."

- It says MUST; therefore any server that doesn't do this is non-compliant?
- It says scope different from the one requested by the *client*. The possibility that the resource owner intercepts this request and changes it doesn't seem to be considered here (it is not strictly the clients request if that happens)
- The purpose seems to be that the client should be told if the scope changes; this would be important if the client requires a certain scope level to work (though this could be solved more generally in many other ways that wouldn't be in the scope of the oauth spec)

Thus, assuming that the server is stating compliance, isn't the assumption completely warranted?

> The only way for a client to know if a token has a scope it to try it, or use a introspection endpoint.  End of story.

An introspection endpoint obviously isn't part of the specification, so isn't relevant to the discussion (though it solves the discussed facebook issue).

You are right though, that the only way for a client to know for sure is to try to use it; Even if the spec mandated always returning the scope to the client, the user could always intercept the return redirection (assuming a non-confidential client) and change the scope there.

Perhaps MUST should change to SHOULD, given that this essentially seems unenforceable?