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
