On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott <andrewarn...@gmail.com>wrote:
> If we can agree that it is useless from a security perspective (and I think > we agree on that by now), then an auth server must not ever issue an access > token to a user agent client without interacting with the user (no > "immediate" mode issuing of access tokens) so the user is aware that some > anonymous client on the web page is trying to access their data, since > there's no assurance whatsoever about which client that is, and whether the > user trusts it. > If anyone disagrees, please explain how you can justify it, in light of the > fact that leaving it as-is means once one client is authorized, the whole > world is authorized by just pretending to be that one client. It might as > well be a "make my data public" switch at the resource server to authorize a > client such that it gets an access token directly without a client secret. > I'm not sure I understand the concerns. The User Agent flow of course can't send back a token to an arbitrary URL - regardless of whether there is user interaction or not. Callback URLs need to be validated - this can be via pre-registration to associate a URL with a client_id or by the user approving the specific callback URL. Any reasons why this isn't secure? > > (Not the muddy the waters, but again, I know client secrets don't add value > when the client is on an uncontrolled machine. Please don't let that > technical hurdle stop you from justifying the status quo in draft 9 of the > spec). > > -- > 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 Mon, Jul 5, 2010 at 10:27 PM, William Mills <wmi...@yahoo-inc.com>wrote: > >> It's not verifiable, but it is as useful in this case as a "user agent" >> string. Not usefule formt he security perspective, but has some utility in >> application tracking. >> >> ------------------------------ >> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf >> Of *Andrew Arnott >> *Sent:* Saturday, July 03, 2010 12:16 PM >> *To:* Eran Hammer-Lahav >> *Cc:* OAuth WG (oauth@ietf.org) >> *Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End user >> authresponse code-and-token's scope parameter) >> >> (this sounds sarcastic, but I'm no being sarcastic... it's a serious >> question/challenge)... >> >> Why not just remove the client_id parameter from the user-agent flow? >> It's absolutely meaningless to security. It's only perceivable benefit is >> that the auth server can possible display to the user the client being >> authorized or the list of previously authorized clients. But again, that's >> totally meaningless if not verified. >> >> -- >> 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 Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <andrewarn...@gmail.com>wrote: >> >>> On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav >>> <e...@hueniverse.com>wrote: >>> >>>> 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. >>>> >>> Good point. I wasn't imagining that far through it. Not to deny that >>> most redirection URLs may just return a straight script that passes it to >>> the parent window, but that seems pretty irresponsible to the host that's >>> doing it -- because of the enormous security hole it opens up. Some client >>> is trusted enough to authorize (by the user and auth server), receives an >>> access token it wasn't expecting, and then blindly forwards it onto whoever >>> wants it. Yikes. I sure hope these access tokens have *very* limited >>> scope (like, I'd prefer none myself). >>> >>> I was about to describe how an active server could alleviate that by >>> signing the original request using the state parameter, but I realized I'm >>> solving a problem that the web server flow (or nowadays that the >>> authorization code mode as I guess it's called) already solves. So I guess >>> I just need to bite the bullet and accept that the user agent flow is >>> *totally >>> *insecure for web clients, and thus very special care must be taken to >>> enable native clients without opening up the web client hole. >>> >>> Sorry to sound so negative about it. Enabling this scenario seems really >>> important to me as well -- I just am against doing it when it can't be >>> secured in some way. Seriously... as is, once you authorize any client, >>> you've authorized them all, including clients not even running on your >>> computer. I guess this answers how I was visiting a site a few days ago and >>> was amazed that it knew who I was (via Facebook) and was displaying my name >>> and photo when I never logged into the site. I was shocked it knew who I >>> was. Enter living in Incognito mode from now on. >>> >> >> > > _______________________________________________ > 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
