I guess as a minimum then, user-agent clients should never be issued access tokens without explicit user interaction? Otherwise every web site around will automatically know who I am on facebook and who my friends are as soon as I authorize the one client that is popular.
Or am I missing something? -- 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 10:02 AM, Eran Hammer-Lahav <[email protected]>wrote: > 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]> > 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]] *On Behalf > Of *Andrew Arnott > *Sent:* Friday, July 02, 2010 9:26 AM > *To:* OAuth WG ([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 the > access_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
