Yes, I agree the end user has to be present (or at least logged in with a cookie, typically) for the client to obtain an access token. But the user doesn't have to interact with the auth server at all or even be aware the a client web script is requesting an access token if that client script claims to have a client_id of another client the user has already authorized, and the auth server then issues the access token without confirmation with the user.
And once the access token is obtained, that access token can be sent off to the evil script's master to use on another computer even. The only mitigation from this particular aspect of the portability of the access token that I can think of would be if the auth server and resource server are on the same domain, and the auth server sent an HTTP-only cookie to the client that would have to be present, paired with the access token, in the HTTP request at the resource server in order to be considered valid. That should defeat sending the access token away. But other evil things can be done with a illegitimately obtained access token that this wouldn't prevent. -- 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 9:43 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote: > It is used as a hint, but one the end-user can help verify. The security > consideration section needs to make this clear. > > EHL > > > > On 7/3/10 12:15 PM, "Andrew Arnott" <andrewarn...@gmail.com> wrote: > > (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
