Subject: [OAUTH-WG] Concerns about Implicit Grant flow

From: Kushal Dave <[email-masked]>
Date: Wed, 6 Jul 2011 16:08:05 -0400

Hello!

Foursquare recently encountered a scary example of a client accidentally
leaking user tokens as part of the implicit grant flow. It turns out the
official "Tweet this" button provided by twitter grabs the URL, including
fragment, at the time of page load, before the client's Javascript has had a
chance to elide the access_token hash value. And it's easy to imagine lots
of other sharing and analytics tools could be similarly aggressive in
transmitting hash values outside of the page.

We've thought a lot about what to do about this, short of disabling the flow
entirely. One thing that seems viable is to make the "access token" in this
flow actually a one-time use token. The requesting page would then make a
JSONP request exchanging the one-time use token for a permanent token that
is never visible in the URL. Has this come up? Have you had any feedback
from other implementors?

We're not excited about such a blatant deviation from the spec, but we're
not sure what else to do.

Cheers,
Kushal

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Jul 2011 16:31:58 -0400

You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
"implicit" flow was to save a roundtrip to the server for light clients
with limited lifespans, and it's a tradeoff between security, ease of
implementation, and performance.

 -- Justin

On Wed, 2011-07-06 at 16:08 -0400, Kushal Dave wrote:
> Hello!
> 
> 
> Foursquare recently encountered a scary example of a client
> accidentally leaking user tokens as part of the implicit grant flow.
> It turns out the official "Tweet this" button provided by twitter
> grabs the URL, including fragment, at the time of page load, before
> the client's Javascript has had a chance to elide the access_token
> hash value. And it's easy to imagine lots of other sharing and
> analytics tools could be similarly aggressive in transmitting hash
> values outside of the page.
> 
> 
> We've thought a lot about what to do about this, short of disabling
> the flow entirely. One thing that seems viable is to make the "access
> token" in this flow actually a one-time use token. The requesting page
> would then make a JSONP request exchanging the one-time use token for
> a permanent token that is never visible in the URL. Has this come up?
> Have you had any feedback from other implementors?
> 
> 
> We're not excited about such a blatant deviation from the spec, but
> we're not sure what else to do.
> 
> 
> Cheers,
> Kushal

---

From: Karim <[email-masked]>
Date: Wed, 6 Jul 2011 22:39:08 +0200

Correct me if i'm wrong, this case is handled by the nonce and time-stamp
values ?

On 6 July 2011 22:31, Justin Richer <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Eaton <[email-masked]>
Date: Wed, 6 Jul 2011 13:41:40 -0700

> implementation, and performance.

Yep.  Two other options.

- give out authorization codes via the user-agent flow.  We've implemented a
variation of this based on HTML5 and window.postMessage.

- use a fixed callback URL for the user-agent flow.  Make sure that fixed
callback URL does not run random bits of script.  Then have that fixed
callback URL use javascript to convey the token to other pages on the same
origin.

It's a bad idea to use the user-agent flow without a specific whitelist of
callback URLs which can receive the token.

---

From: Justin Richer <[email-masked]>
Date: Wed, 6 Jul 2011 16:52:25 -0400

> 
> - give out authorization codes via the user-agent flow.  We've
> implemented a variation of this based on HTML5 and window.postMessage.
> 
Caveat: This will run you off-spec.

> - use a fixed callback URL for the user-agent flow.  Make sure that
> fixed callback URL does not run random bits of script.  Then have that
> fixed callback URL use javascript to convey the token to other pages
> on the same origin.
>
> It's a bad idea to use the user-agent flow without a specific
> whitelist of callback URLs which can receive the token.

Brian's nailed it here. The best way to use this flow is to control the
landing page as much as possible.

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 16:47:57 -0700

These are all good ways to mitigate the issue, but they don't solve it. If you are running third-party scripts on the redirection URI page, all bets are off as to who is going to end up with the access token, authorization code, etc. It is pretty bad security to run any kind of third party code on your login page, which in many cases, the redirection page is (Facebook connect, etc.).

The callback whitelist doesn't really add any protection against this specific leakage given that no large provider has the resources to scan every redirection URI page for third-party scripts, analyze them, and block such URIs (and do this continuously to monitor changes).

What these alternatives do is reduce the likelihood of a leaked credential being abused, but they are still going to be exposed if all you change is the flow, not the redirection URI page.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Wednesday, July 06, 2011 1:42 PM
To: Justin Richer
Cc: Kushal Dave; [email-masked]
Subject: Re: [OAUTH-WG] Concerns about Implicit Grant flow

On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Yep.  Two other options.

- give out authorization codes via the user-agent flow.  We've implemented a variation of this based on HTML5 and window.postMessage.

- use a fixed callback URL for the user-agent flow.  Make sure that fixed callback URL does not run random bits of script.  Then have that fixed callback URL use javascript to convey the token to other pages on the same origin.

It's a bad idea to use the user-agent flow without a specific whitelist of callback URLs which can receive the token.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 16:43:23 -0700

I'm going to add text warning about third-party scripts included on the redirection URI endpoint.

The right solution here is to make sure no script is executed before the client code gets hold of the access token and hides it. Ideally, the landing page does not include any third party scripts, and those included should know better than to include the fragment which in today's web applications are heavily used to manage internal state, not to anchor a part of the document.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kushal Dave
Sent: Wednesday, July 06, 2011 1:08 PM
To: [email-masked]
Subject: [OAUTH-WG] Concerns about Implicit Grant flow

Hello!

Foursquare recently encountered a scary example of a client accidentally leaking user tokens as part of the implicit grant flow. It turns out the official "Tweet this" button provided by twitter grabs the URL, including fragment, at the time of page load, before the client's Javascript has had a chance to elide the access_token hash value. And it's easy to imagine lots of other sharing and analytics tools could be similarly aggressive in transmitting hash values outside of the page.

We've thought a lot about what to do about this, short of disabling the flow entirely. One thing that seems viable is to make the "access token" in this flow actually a one-time use token. The requesting page would then make a JSONP request exchanging the one-time use token for a permanent token that is never visible in the URL. Has this come up? Have you had any feedback from other implementors?

We're not excited about such a blatant deviation from the spec, but we're not sure what else to do.

Cheers,
Kushal

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 16:50:37 -0700

What triggers this flow? If you are using the authorization endpoint with a different response_type, it would be helpful if you shared that with the wg as currently, that's simply not allowed (the values are not extensible). I am going to change that in -17, but based on the requirement presented by Paul Tarjan. Additional use cases would be extremely helpful.

Also, I'd hate to see Google being the first to violate the protocol in that scale.

EHL