No, that's a really simple recipe for disaster. Flickr kept opening up this security hole. They would allow applications to get new tokens simply using their api key & secret and a user's session cookies. If we assume that for a desktop user-agent will expose its secrets then this is a really easy way to gain access to peoples' accounts.
See: http://ianloic.com/2006/12/23/flickr_authentication_security/ and: http://ianloic.com/2009/01/05/no-more-secrets/ Ian On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu <mscurte...@google.com> wrote: > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <andrewarn...@gmail.com> wrote: >> 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? > > Most likely user interaction will be required for the first time, but > after that an immediate mode (no user interaction) is almost a must. > JavaScript clients will probably not be issued refresh tokens and > access tokens are short lived. It would not be practical to ask the > user every hour or so. In immediate mode there is no explicit user > interaction, but the user must be at the browser and have an active > session with the authz server. > > How would other web sites know about your facebook account? Are you > worried if the same JavaScript widget is embedded in multiple site and > that these instances share state? Or that the widget shares state with > the embedding site/page? Not sure about that. > > Marius > > >> -- >> 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 <e...@hueniverse.com> >> 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:andrewarn...@gmail.com] >>> Sent: Friday, July 02, 2010 9:51 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org) >>> 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 <e...@hueniverse.com> >>> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> Andrew Arnott >>> Sent: Friday, July 02, 2010 9:26 AM >>> To: OAuth WG (oauth@ietf.org) >>> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Ian McKellar <http://ian.mckellar.org/> i...@mckellar.org: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
