The issue is that it is hard (or even impossible) to prevent another user-agent client from imitating another user-agent client. A pre-registered redirection URI does very little to help. In most cases, such a URI will point to a web page with a script that will extract the information and pass it to the parent frame. This means any client can get hold of the access token as long as it was the parent.
If you use immediate with a user-agent flow, the script running in the user-agent will get the access token by pretending to be another client which was already granted access. Since there is no way to authenticate the user-agent client, there is no way for the resource at the redirection URI to authenticate the client - meaning that it can be used by others. Immediate mode for user-agent clients takes away the only security safeguard which is the explicit end-user approval for whatever is going on on front of him or her. EHL On 7/6/10 9:31 PM, "Evan Gilbert" <uid...@google.com> wrote: 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
