At the end of the day, there isn't much you can do about user-agent clients. Even a registered redirection URI doesn't really help because that endpoint too cannot authenticate the client.
EHL From: Andrew Arnott [mailto:[email protected]] Sent: Friday, July 02, 2010 9:51 AM To: Eran Hammer-Lahav Cc: OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope parameter Ah! Yes I'd missed the second scope parameter that web servers have the opportunity to see. And your point makes sense. Is this reduced scope on the access token, and the encouragement for a registered redirect_uri, the only mitigations we have for this possible attack? Popular client app A is broadly authorized by users on the web. Evil client app B is added as javascript on a web site. Victim visits that web site, and the evil client quietly requests an access token from auth server using a request claiming to be from client app A. Since client app A wasn't required to register a redirect_uri and did not do so, client app B is successful in supplying its own redirect_uri and gains an access token without user intervention or knowledge, since the user had already authorized client A and the auth server just freely granted a new access token. Client app B then uses AJAX to send access token to the attacker, who can now exploit the access token from a separate machine. I brought this attack up once before. I really feel the spec should forbid issuing access tokens directly to user-agent clients when they haven't registered a redirect_uri. Another mitigation is that implicit re-issuing of an access token to a previously authorized client should be banned without a registered redirect_uri (although this only reduces the risk, as the user is still presented with the wrong client name). Thoughts? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: Scope is specific to the access token, not the code. In fact, I expect some providers to issue an access token with a lesser scope than that provided when exchanging the authorization code later (which will include another scope). This is because the authorization server can authenticate the client when using the authorization code and provide greater access. EHL From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Andrew Arnott Sent: Friday, July 02, 2010 9:26 AM To: OAuth WG ([email protected]<mailto:[email protected]>) Subject: [OAUTH-WG] End user auth response code-and-token's scope parameter If the response type is code-and-token, the authorization server adds the codeand state parameters to the redirection URI query component and theaccess_token, scope, and expires_in to the redirection URI fragment using theapplication/x-www-form-urlencoded format as defined by... Since the scope applies equally to both the code and access_token parameters, it seems that scope should be included in the URI query part so it is available to the web server as well as the user-agent. While the scope remains in the fragment, the client's web server won't know whether the full scope it requested was actually granted. Was there an advantage to including the scope only in the #fragment, or was this just an oversight? Thanks. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
