Subject: [OAUTH-WG] Security of user agent clients (WAS: End user auth response code-and-token's scope parameter)

From: Andrew Arnott <[email-masked]>
Date: Fri, 2 Jul 2010 11:02:42 -0700

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?
--
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 <[email-masked]>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:[email-masked]]
> *Sent:* Friday, July 02, 2010 9:51 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
> *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 <[email-masked]>
> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew Arnott
> *Sent:* Friday, July 02, 2010 9:26 AM
> *To:* OAuth WG ([email-masked])
> *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 the
> access_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
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Jul 2010 12:17:56 -0700

> 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

>> From: Andrew Arnott [mailto:[email-masked]]
>> Sent: Friday, July 02, 2010 9:51 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG ([email-masked])
>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's scope
>> parameter
>>
>>
>>
>> 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
>> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Andrew Arnott
>> Sent: Friday, July 02, 2010 9:26 AM
>> To: OAuth WG ([email-masked])
>> 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
>> Was there an advantage to including the scope only in the #fragment, or
>> was this just an oversight?
>>
>>
>>
>> Thanks.
>>
>> --
>> Andrew Arnott
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Ian McKellar <[email-masked]>
Date: Sat, 3 Jul 2010 09:09:34 +1200

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

-- 
Ian McKellar  <http://ian.mckellar.org/>
[email-masked]: email | jabber | msn
ianloic: flickr | aim | yahoo | skype | linkedin | etc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 14:13:39 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ian McKellar
> Sent: Friday, July 02, 2010 2:10 PM
> To: Marius Scurtescu
> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user auth
> response code-and-token's scope parameter)
> 
> 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.
> 
> >> 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.
> >> "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
> >> <[email-masked]>
> >> wrote:
> >>>
> >>> clients. Even a registered redirection URI doesn’t really help
> >>> because that endpoint too cannot authenticate the client.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> 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
> >>> 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
> >>>
> >>> 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: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of Andrew Arnott
> >>> 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...
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>

---

From: Andrew Arnott <[email-masked]>
Date: Fri, 2 Jul 2010 19:24:05 -0700

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.

On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav <[email-masked]>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
>
> > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <[email-masked]
> >
> > wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Jul 2010 21:12:32 -0700

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:[email-masked]]
Sent: Friday, July 02, 2010 7:24 PM
To: Eran Hammer-Lahav
Cc: Ian McKellar; Marius Scurtescu; OAuth WG ([email-masked])
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 <[email-masked]<mailto:[email-masked]>> 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

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Ian McKellar
> Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
> On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
> wrote:
> > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <[email-masked]<mailto:[email-masked]>>
> wrote:
> >> <[email-masked]<mailto:[email-masked]>>
> >> 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
> >>> From: Andrew Arnott [mailto:[email-masked]<mailto:[email-masked]>]
> >>> Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav
> >>> <[email-masked]<mailto:[email-masked]>>
> >>> wrote:
> >>>
> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> >>> Behalf Of Andrew Arnott
> >>> To: OAuth WG ([email-masked]<mailto:[email-masked]>)
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>: email | jabber | msn
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 03 Jul 2010 12:19:32 +0200

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
>
> *Sent:* Friday, July 02, 2010 7:24 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Ian McKellar; Marius Scurtescu; OAuth WG ([email-masked])
> *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
> 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
>
>
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
>
> > Of Ian McKellar
> > Cc: OAuth WG ([email-masked] <mailto:[email-masked]>)
>
> applications to get
> > On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu 
> <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott 
> <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > >> <[email-masked] <mailto:[email-masked]>>
> > >> wrote:
> > >>>
> > >>> Cc: OAuth WG ([email-masked] <mailto:[email-masked]>)
> > >>> <[email-masked] <mailto:[email-masked]>>
> > >>> wrote:
> > >>>
> > >>> From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On
> > >>> Behalf Of Andrew Arnott
> > >>> To: OAuth WG ([email-masked] <mailto:[email-masked]>)
> > >> [email-masked] <mailto:[email-masked]>
> > > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>: email | jabber | msn
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Ian McKellar <[email-masked]>
Date: Sun, 4 Jul 2010 00:53:31 +1200

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
<[email-masked]> wrote:
> Is something as the user agent flow used in the wild today? What security
> means are used their?
>
> 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.
>
> 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
>
>
>
> 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

---

From: Luke Shepard <[email-masked]>
Date: Sat, 3 Jul 2010 07:15:21 -0700

On Jul 3, 2010, at 3:19 AM, Torsten Lodderstedt wrote:

> Is something as the user agent flow used in the wild today? What security means are used their?

Yes. Facebook has shipped it: http://developers.facebook.com/docs/authentication/desktop

We require either pre-registration of the callback URL, or that the app uses a standard redirect URL on Facebook.com (which could only be used by a desktop app).

> 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.

Correct. The main purpose of the user-agent flow is to allow a Javascript client to obtain an access token without requiring the presence of a secret, or a server.

There are cases when you have an app without a server component, and you don't want to require a secret key (which can be revealed)

---

From: Andrew Arnott <[email-masked]>
Date: Sat, 3 Jul 2010 12:12:29 -0700

On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> script that will pass the parameter to the **parent** window which can be
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.

---

From: Andrew Arnott <[email-masked]>
Date: Sat, 3 Jul 2010 12:15:33 -0700

(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.

On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <[email-masked]>wrote:

> 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.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 3 Jul 2010 21:42:33 -0700

The user-agent security is based on the presence of the end-user. This is important. It is not like a client with the same ID can just go and ask for an access token (if one was previously approved). The end-user must be present. How the end-user presence is verified is something each server has to figure out.

EHL

On 7/3/10 12:12 PM, "Andrew Arnott" <[email-masked]> wrote:

On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <[email-masked]> 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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 3 Jul 2010 21:43:37 -0700

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" <[email-masked]> 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.

On Sat, Jul 3, 2010 at 12:12 PM, Andrew Arnott <[email-masked]> wrote:
On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav <[email-masked]> 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).

---

From: Andrew Arnott <[email-masked]>
Date: Sat, 3 Jul 2010 21:52:35 -0700

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.

On Sat, Jul 3, 2010 at 9:43 PM, Eran Hammer-Lahav <[email-masked]>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
>
>
>

---

From: "William Mills" <[email-masked]>
Date: Mon, 5 Jul 2010 22:27:26 -0700

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew Arnott
	Sent: Saturday, July 03, 2010 12:16 PM
	To: Eran Hammer-Lahav
	Cc: OAuth WG ([email-masked])
	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
<[email-masked]> wrote:

		On Fri, Jul 2, 2010 at 9:12 PM, Eran Hammer-Lahav
<[email-masked]> 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.

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 6 Jul 2010 12:49:48 -0700

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.

(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 <[email-masked]> wrote:

> string.  Not usefule formt he security perspective, but has some utility in
> application tracking.
>
>  ------------------------------
> *Sent:* Saturday, July 03, 2010 12:16 PM
> *To:* Eran Hammer-Lahav
> *Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End user
> authresponse code-and-token's scope parameter)
>
>>> 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
>> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Jul 2010 13:03:08 -0700

There are known issues with using cookies and other passive authentication measures, and we should document them. However, this all depends on the security needs of the service, and these patterns are already deployed in services such as FB. It would be useful to find out how they address these concerns.

EHL

On 7/6/10 12:49 PM, "Andrew Arnott" <[email-masked]> 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.

(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 <[email-masked]> 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: [email-masked]  [mailto:[email-masked]] On Behalf Of Andrew  Arnott
Sent: Saturday, July 03, 2010 12:16 PM
To: Eran  Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re:  [OAUTH-WG] Security of user agent clients (WAS: End user authresponse  code-and-token's scope parameter)

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Jul 2010 21:31:13 -0700

> 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?

> On Mon, Jul 5, 2010 at 10:27 PM, William Mills <[email-masked]>wrote:
>
>> 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

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 6 Jul 2010 22:21:49 -0700

On Tue, Jul 6, 2010 at 12:49 PM, Andrew Arnott <[email-masked]> wrote:
> we agree on that by now),

I don't think this is useless. As Evan mentioned, a JavaScript client
could register and provide a redirect_uri (or redirect_uri pattern)
and also a display name. In this case the ID is needed.

> then an auth server must not ever issue an access

If the user has to be involved every time an access token is issued
then the whole flow becomes unusable. Access tokens typically expire
in an hour or so, you cannot keep prompting the user that often.

Marius

>> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End user
>>> wants it.  Yikes.  I sure hope these access tokens have very limited scope
>>> 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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 12:47:12 -0700

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" <[email-masked]> wrote:

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?

---

From: Michael D Adams <[email-masked]>
Date: Wed, 7 Jul 2010 13:06:59 -0700

On Wed, Jul 7, 2010 at 12:47 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> 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.

The script doesn't have to naively pass information to the parent.  It
could either make an explicit check to make sure the parent is in the
same domain, or rely on communication techniques that respect the
same-origin policy.

Pros:
With a pre-registered redirection URI, this prevents the specific case
you mentioned above.  Are there other cases where this wouldn't work?

Cons:
Requiring such a check would add implementation load to clients.
Servers would not know if the (good-guy) client is conformant.
Does it break the user-agent flow entirely?  Are there implementations
that require this blind cross domain communication?

Mike
--mdawaffe

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 13:11:39 -0700

Thanks. Browser security is not my area.

It seems to me that this must be documented as all the examples I have seen for such scripts did not include any such security measures.

EHL

On 7/7/10 1:06 PM, "[email-masked]" <[email-masked]> wrote:

Pros:

Cons:

Mike
--mdawaffe

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 07 Jul 2010 16:40:00 -0400

I think this squarely belongs in the Security Consideration section!

In fact, I think that all other items there ought to be written using 
the same template: a) Problem, b) Solution(s) along with pros and cons.

 Igor

Eran Hammer-Lahav wrote:
> It seems to me that this must be documented as all the examples I have 
> seen for such scripts did not include any such security measures.
>
> EHL
>
>
> ------------------------------------------------------------------------
>

---

From: Michael D Adams <[email-masked]>
Date: Wed, 7 Jul 2010 17:47:59 -0700

On Wed, Jul 7, 2010 at 1:11 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> It seems to me that this must be documented as all the examples I have seen
> for such scripts did not include any such security measures.

Nor is it mine.  I know some techniques for cross-origin
communication, but not intimately enough to know all the security
implications raised by each in various browsers.

As a general rule, though, iframes can't talk to one another if they
have different origins.

There are several ways to bend the rule.  Doing so would introduce
security problems for OAuth.

1. Communication via setting URI fragments in other iframes and
detecting such changes in your own iframe.
2. Proxy iframes.

So we should tell people not to (blindly) use those or other
techniques that don't respect the same-origin restriction.

Instead, they could just directly call functions in one iframe from
another iframe (parent.doSomething( blah )).  Browsers will only allow
this between same-origin iframes.

If an implementor needs cross domain functionality, there's a new,
safer technology that allows both ends to whitelist who they talk to.

Cross-document messaging
http://www.w3.org/TR/html5/comms.html#crossDocumentMessages

I'm not familiar with cross-document messaging or how well it's
supported by browsers.

Also note that same-origin security does not protect against malicious
communication between two iframes on the same origin but different
paths.  http://example.com/naive-client/ and
http://example.com/evil-scraper/, for example.

Because of that, the child iframe should probably check its parent's
entire URL, not just the domain/origin.

Mike
--mdawaffe

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 8 Jul 2010 09:43:16 +0200

> I'm not familiar with cross-document messaging or how well it's

It is supported by Firefox 3+, IE 8+, Opera 9+, Safari 4+ and Chrome,
so mostly IE 6/7 should be the problem (as usual ...).
And, by the way, the controversial XAuth completely relies on this technique.

There could be one flow in which the authentication server, instead of
redirecting, would pass the token through postMessage() with a
targetOrigin that was pre-configured by the client, but I guess that
is nothing for the core spec at this moment. Just an idea.

Regards,
 Lukas Rosenstock