FWIW, it could be that the authorization request was authored by neither the client nor the user. An unrelated fourth party can construct an authorization endpoint URL using a client_id that isn't his own and send a user there. This wasn't possible in OAuth 1 because of how it used request tokens.
Regards, Andre DeMarre On Tue, Feb 21, 2012 at 4:38 PM, André DeMarre <[email protected]> wrote: > The consensus seems to be, and I agree, that this shouldn't be > considered an "attack," but that's really just nomenclature. I do > concede that there is a spec issue here that I failed to appreciate at > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued > access token scope is different from the one requested by the client," > it suggests that the authorization server knows what was requested by > the client. That isn't strictly true; it only knows what was in the > authorization request, not who put it there. For the client to truly > know what the auth server wants, (1) it would need to communicate > directly with the client, (2) the client would need to preregister its > desired scope, or (3) the client would need to sign a message that the > user passes to the authorization endpoint. 1 and 3 are clearly not > compatible with the spec, 2 might be; but that's not the point. > > A more correct statement in section 3.3 would be "If the issued access > token scope is different from the one in the authorization request..." > > Regards, > Andre DeMarre > > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <[email protected]> wrote: >> >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote: >> >>> >>> 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? >> >> No the authorization server may at any time for any reason remove a scope >> from a granted access_token or refresh_token. >> >> Reporting back changes in scopes granted along with the access_token is a >> convenience not a security feature. >> >> Assuming it is a security feature and those scopes will continue to be valid >> for the token after granting is a bad design given the OAuth 2 spec. >>> >>>> 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? >> >> A SHOULD may lead people to the conclusion that it is secure. I am happy >> with saying it is not secure the only want to know is to have the client be >> prepared to deal with tokens that do not contain the desired scope when >> used. That is the only 100% solution. >> >> John B. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
