The user agent flow is really useful if you just require user interaction to issue new access tokens. There are big benefits (including security benefits[*]) to not involving the server.
Ian [*] the security benefit being that I never have had to authorize your server to do action on my behalf, only software that's actually running on my computer that I can examine (view source) and audit. On Sat, Jul 3, 2010 at 10:19 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Is something as the user agent flow used in the wild today? What security > means are used their? > > I wonder why we do not drop the user agent flow from the spec because of > security reasons. From my point of view, the web flow could be used to > achieve a similar behavior except the JavaScript client could not directly > obtain its access tokens. Instead a(n) (application internal) protocol must > be used between web site and user agent client to exchange (and refresh) > access tokens. > > Thoughts? > regards, > Torsten. > > Am 03.07.2010 06:12, schrieb Eran Hammer-Lahav: > > You are putting too much weight on the value of redirection URI > registration. Since the same problem exists between the user-agent script > and the server-side component used in the user-agent profile, anyone can > imitate that flow. In most cases, the redirection URI will simply include a > script that will pass the parameter to the *parent* window which can be > anything. If the server-based page is an active page, it still needs to > communicate with the user-agent, which again, can pretend to be that. > > > > As long as the access token is passed back to the user-agent application, > you can imitate it and pretend to be another client. > > > > EHL > > > > From: Andrew Arnott [mailto:andrewarn...@gmail.com] > Sent: Friday, July 02, 2010 7:24 PM > To: Eran Hammer-Lahav > Cc: Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth > response code-and-token's scope parameter) > > > > I agree with the installed client issue it cannot be solved. But for a > browser-based user-agent script, it's particularly dangerous to not solve > it, and I believe it can be solved. By forbidding unregistered redirect_uri > values to be included in the request for a direct access token, user agent > scripts can't (as far as I can imagine) productively spoof other clients. > That is, they could pretend to be the popular client that is already > authorized to get another access token, but the token would be sent to the > real client via redirect and not be accessible to the evil client. > > > > And it's the web-based client that I am most concerned about. An installed > client already has some degree of trust with the user since it is software > running on the OS. But any and every web site the user visits could crack > your Facebook account (or any other OAuth-enabled resource server) simply by > formulating the request with a client_id that has likely already been > authorized in a hidden iframe. > > > > I see this as a real problem, and I'm proposing what I believe is a working > solution. Again, I'm not trying to solve the installed client problem and I > think that's much less severe anyway. But the web-based one must be solved, > and this is a way to solve it IMO. > > -- > 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 2:13 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: > > There is nothing you can do to protect any non-server-based client from > imitating another client. All you can do is require the end-use to be > present when you cannot trust who the client is (assuming you trust the user > to know what they are doing). What providers need to do is understand this > and design their security and token scoping attributes according to their > own attack vectors. The spec should highlight these issues, but cannot solve > them. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > >> Of Ian McKellar >> Sent: Friday, July 02, 2010 2:10 PM >> To: Marius Scurtescu >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth >> response code-and-token's scope parameter) >> >> 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 > _______________________________________________ > 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 > > > _______________________________________________ > 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
