Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

From: Oleg Gryb <[email-masked]>
Date: Sun, 1 Aug 2010 17:12:51 -0700 (PDT)

Here is an example with Location header. I don't see URI with access token been truncated. See Location header generated by JSP and actual redirect that browser followed below.

red.jsp (Running on local Tomcat):

<% String url = "http://www.google.com#access_token=123"; response.sendRedirect(url); %> 

Live HTTP headers trace for Iceweasel Browser:

http://localhost:8080/red.jsp

GET /red.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=236DAD3EA6288BDC6A780CFFFB9F83E2; Path=/
Location: http://www.google.com#access_token=123
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Mon, 02 Aug 2010 00:18:01 GMT
----------------------------------------------------------
http://www.google.com/#access_token=123

GET / HTTP/1.1
Host: www.google.com

--- On Sun, 8/1/10, Oleg Gryb <[email-masked]> wrote:

> From: Oleg Gryb <[email-masked]>
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
> To: "Marius Scurtescu" <[email-masked]>, "Bouiaw" <[email-masked]>
> Cc: [email-masked]
> Date: Sunday, August 1, 2010, 7:18 PM
> I'll need to check if it's true for
> dynamic redirects that use Location header, 
> but right now I can provide an example where JavaScripts
> are used for redirects 
> in which case access token is send in a URL.
> 
> Let us assume that you've implemented an endpoint on your
> authz server as a JSP 
> that populates access token dynamically:
> 
> <html>
> <body onload="window.location.href = 
> 'http://www.google.com#access_token=<%=var_with_token%>'">
> </body>
> </html>
> 
> After JSP container expanded the variable, the response
> that browser will see 
> looks as follows:
> 
> 
> <html>
> <body onload="window.location.href = 'http://www.google.com#access_token=123'">
> </body>
> </html>
> 
> To test the page above, I put it to my local Apache web
> server and then accessed 
> it using Iceweasel browser. I've used HTTP Live Headers to
> see all redirects. 
> The trace is below. Please let me know what I'm missing.
> The last GET has access 
> token in it.
> 
> http://localhost/red.html
> 
> GET /red.html HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018 
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT
> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip
> 
> HTTP/1.x 200 OK
> Date: Sun, 01 Aug 2010 23:16:17 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with
> Suhosin-Patch 
> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT
> Etag: "dfa53-67-48ccb4133b4c0"-gzip
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 110
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: text/html
> ----------------------------------------------------------
> http://www.google.com/#access_token=123
> 
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018 
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://localhost/red.html
> Cookie: 
> PREF=ID=0f1fa5297d3f9d6a:U=f5ef3a217b0cd5bf:TM=1277864220:LM=1278796823:GM=1:S=j8uhrMH9ofdi5YZo;
> NID=37=J2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd;
> ; 
> SID=DQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ;
>  HSID=ASoUGayYF7At1XErl
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message ----
> From: Marius Scurtescu <[email-masked]>
> To: Bouiaw <[email-masked]>
> Cc: Oleg Gryb <[email-masked]>;
> [email-masked]
> Sent: Sun, August 1, 2010 1:03:36 PM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in
> OAuth 2.0?
> 
> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw <[email-masked]>
> wrote:
> > Does the redirect with fragment in URL without sending
> it to the
> > server have been tested with all main browsers ?
> 
> AFAIK this is how all major browsers behave. Does anyone
> know
> otherwise? Browsers that don't respect this?
> 
> Marius
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
>       
>

---

From: David Recordon <[email-masked]>
Date: Sun, 1 Aug 2010 17:24:13 -0700

Host: www.google.com

The fragment wasn't sent by the browser to the server.

--David

On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb <[email-masked]> wrote:

> Here is an example with Location header. I don't see URI with access token
> been truncated. See Location header generated by JSP and actual redirect
> that browser followed below.
>
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7)
> Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1)
> > <body onload="window.location.href = '
> http://www.google.com#access_token=123'">
> > </body>
> > </html>
> >

---

From: Oleg Gryb <[email-masked]>
Date: Sun, 1 Aug 2010 17:42:53 -0700 (PDT)

David,

Yes, you're right, I've should have paid attention to the GET line, not to the URL above. Browser honors fragment sent in Location, but it's not on the GET line. 

I've also enabled Tomcat access log and could not find the fragment there.

My apologies. 

--- On Sun, 8/1/10, David Recordon <[email-masked]> wrote:

From: David Recordon <[email-masked]>
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
To: [email-masked]
Cc: [email-masked]
Date: Sunday, August 1, 2010, 8:24 PM

GET /red.jsp HTTP/1.1

Host: localhost:8080

Keep-Alive: 300

Connection: keep-alive

Content-Length: 0

GET / HTTP/1.1

Host: www.google.com

OAuth mailing list

[email-masked]

---

From: Oleg Gryb <[email-masked]>
Date: Sun, 1 Aug 2010 19:47:52 -0700 (PDT)

I've just verified Ruby and Perl's user agents as well: both worked as expected - no fragments in the web log files. It adds confidence. Thanks to everyone who has answered. The code that I've used is below:

--------------------------------------------------------------------------------
use LWP;

my $browser = LWP::UserAgent->new;

if ($browser) {
   $browser->agent("User-Agent: Mozilla/4.0");
   my $req = HTTP::Request->new(GET => "http://localhost:8080/tmp#access_token=123");
   my $res = $browser->request($req);
}
-------------------------------------------------------------------------------
require "httpclient.rb"

client = HTTPClient.new
client.get('http://localhost:8080/ruby#access_token=123')

From: Oleg Gryb <[email-masked]>
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
To: [email-masked], "David Recordon" <[email-masked]>
Cc: [email-masked]
Date: Sunday, August 1, 2010, 8:42 PM

David,

My apologies. 

GET /red.jsp HTTP/1.1

Host: localhost:8080

Keep-Alive: 300

Connection: keep-alive

Content-Length: 0

GET / HTTP/1.1

Host: www.google.com

OAuth mailing list

[email-masked]

---

From: Oleg Gryb <[email-masked]>
Date: Mon, 2 Aug 2010 09:23:26 -0700 (PDT)

What about browsing history? I've just run the JSP below  in Tomcat and found 
out that Firefox remembers the redirect in the  browsing history. It'll be a 
problem in a shared desktop or Internet  kiosk environment.

JSP:
<% String url = "http://localhost:8080#access_token=123"; 
response.sendRedirect(url); %>

The URL that I can see in Firefox->History: 
http://localhost:8080#access_token=123

Why don't you want to send the access token in a response's body along with a 
JavaScript that will redirect the browser to the URL without token on page load?

Oleg.

________________________________
From: Oleg Gryb <[email-masked]>
To: David Recordon <[email-masked]>
Cc: [email-masked]
Sent: Sun, August 1, 2010 7:47:52 PM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

I've just verified Ruby and Perl's user agents as well: both worked as expected 
- no fragments in the web log files. It adds confidence. Thanks to everyone who 
has answered. The code that I've used is below:

if ($browser) {
   $browser->agent("User-Agent: Mozilla/4.0");
   my $req = HTTP::Request->new(GET => 
"http://localhost:8080/tmp#access_token=123");
   my $res = $browser->request($req);
}
-------------------------------------------------------------------------------
require "httpclient.rb"

client = HTTPClient.new

--- On Sun, 8/1/10, Oleg Gryb <[email-masked]> wrote:

>Yes, you're right, I've should have paid attention to the GET line, not to the 
>URL above. Browser honors fragment sent in Location, but it's not on the GET 
>line. 
>
>

--David

Here is an example with Location header. I don't see URI with access token been 
truncated. See Location header generated by JSP and actual redirect that browser 
followed below.
>'http://www.google.com#access_token=123'">
>> </body>
>> </html>
>>

---

From: Brian Eaton <[email-masked]>
Date: Mon, 2 Aug 2010 12:47:10 -0700

On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb <[email-masked]> wrote:
>
> What about browsing history? I've just run the JSP below in Tomcat and found out that Firefox remembers the redirect in the browsing history. It'll be a problem in a shared desktop or Internet kiosk environment.

I think the best practice for authentication tokens passed on URLs is
to clean the URL as soon as it is received.

For the web server flow, that would mean sending a 302 after receiving
the authorization code.

For the user-agent/javascript flow, that would mean copying the token
into a cookie or a javascript variable, and then using
window.location.replace() to clean the URL.

My javascript ninja sources tell me that location.replace() cleans the
browser history, but I haven't actually tested it.  The mozilla
documentation is very clear on the expected behavior:

https://developer.mozilla.org/en/window.location

"Replace the current document with the one at the provided URL. The
difference from the assign() method is that after using replace() the
current page will not be saved in session history, meaning the user
won't be able to use the Back button to navigate to it."

Cheers,
Brian

---

From: David Recordon <[email-masked]>
Date: Mon, 2 Aug 2010 14:38:39 -0700

A richer history API is also coming as a part of HTML5.
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html

On Mon, Aug 2, 2010 at 12:47 PM, Brian Eaton <[email-masked]> wrote:

> > What about browsing history? I've just run the JSP below in Tomcat and
> found out that Firefox remembers the redirect in the browsing history. It'll
> be a problem in a shared desktop or Internet kiosk environment.
>

---

From: David Stanek <[email-masked]>
Date: Mon, 2 Aug 2010 21:15:24 -0400

On Sun, Aug 1, 2010 at 10:47 PM, Oleg Gryb <[email-masked]> wrote:

> I've just verified Ruby and Perl's user agents as well: both worked as
> expected - no fragments in the web log files. It adds confidence. Thanks to
> everyone who has answered.

I just verified that the Python urllib client does send the fragment to the
server. I've created a patch and will be created a bug on the Python
tracker.

Does anyone know what RFC actually talks about not sending the fragment?
I've seen 3986 where it explains that a fragment isn't really a part of the
URI, but it's doesn't specifically say that the client should not send it to
the server.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek

---

From: Brian Eaton <[email-masked]>
Date: Mon, 2 Aug 2010 20:31:56 -0700

> server. I've created a patch and will be created a bug on the Python

Cool, but this doesn't seem relevant to the user-agent profile.  Market
penetration of browsers written in python is limited.

> URI, but it's doesn't specifically say that the client should not send it to

No idea.  This might be one of those things that all the browsers implement,
but has never been fully specified.

There are a few notes on referers in the browsersec wiki:
http://code.google.com/p/browsersec/wiki/Part1

Cheers,
Brian

---

From: Oleg Gryb <[email-masked]>
Date: Mon, 2 Aug 2010 22:21:23 -0700 (PDT)

Brian,

I think, it's not so much about browsers written in Python, as about automation 
(crawler) that somebody might want to use. Also, since Python user agent works 
this way, we might have others user agents like that, e.g. did anyone check all 
obscure browsers on smart phones?

Returning to our discussion about necessity of passing access_token in URL's 
fragment, I've read both your proposal for changing  v.9 and the current v.10, 
but still don't understand why we need access_token in a fragment.

I think, a safer solution would be to return an access token in a response form, 
not in Location header. This way, we'll avoid problems with user agents that 
David Stanek described and prevent browsers from storing tokens in a browser's 
history.

In sense of efficiency, I don't think that we'll loose much. We might even 
eliminate two last steps. If you're still concerned about caching pages in a 
browser, it's a known problem for any sensitive pages and it can be resolved, 
e.g. by adding HTTP headers in response: Pragma:No-cache and 
Cache-Control:no-cache.

Here is how JSP that generates access token can look like:
form.jsp
-----------------------------------------------------------
<HTML>
<HEAD>
<%
   response.addHeader("Pragma", "No-cache");
   response.addHeader("Cache-Control", "no-cache");
   String token = "123"; // It could be more complicated of course
%>
<script>

function process(token, url) {
   document.params.setAttribute("method", "POST");
   document.params.setAttribute("action", url);
   document.params.submit();
}
</script>
</HEAD>
<BODY 
onload="process(document.params.access_token.value,document.params.url.value)">
<form name="params"> 
<input type="hidden" name="access_token" value="<%=token%>"/>
http://localhost:8080/resource.jsp"/>
</form>
</BODY>
</HTML>

resource.jsp in this example will take the request with access_token, verify it 
and send a response with the requested resource back to the browser. In the 
example below it just prints out the request (with access_token in it). 

It means that after modified step C, you'll have just one more step that takes 
URL from the form and POST the form to that URL. Ajax might work as well. No 
need in passing access token in a fragment.

resource.jsp that I've used for testing (it simply prints the request coming 
from form.jsp):
<HTML>
<HEAD>
<%
   String input ="";
   try {
      java.io.BufferedReader reader = request.getReader();
      String line = reader.readLine();
      while (line != null) {
         input += line + "\n";
         line = reader.readLine();
      }

   }
   catch (Exception ex) {
   }
%>
<script>
</script>
</HEAD>
<BODY>
<%=input%>
</BODY>
</HTML>

________________________________
From: Brian Eaton <[email-masked]>
To: David Stanek <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Mon, August 2, 2010 8:31:56 PM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

I just verified that the Python urllib client does send the fragment to the 
server. I've created a patch and will be created a bug on the Python tracker.

Does anyone know what RFC actually talks about not sending the fragment? I've 
seen 3986 where it explains that a fragment isn't really a part of the URI, but 
it's doesn't specifically say that the client should not send it to the server.

No idea.  This might be one of those things that all the browsers implement, but 
has never been fully specified.

There are a few notes on referers in the browsersec 
wiki: http://code.google.com/p/browsersec/wiki/Part1

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Aug 2010 22:38:11 -0700

RFC 2616 (5.1.2) defines the request URI as:

Request-URI    = "*" | absoluteURI | abs_path | authority

And imports 'absoluteURI' from RFC 2396 (3):

absoluteURI   = scheme ":" ( hier_part | opaque_part )
      hier_part   = ( net_path | abs_path ) [ "?" query ]
opaque_part   = uric_no_slash *uric

      uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                      "&" | "=" | "+" | "$" | ","

      uric          = reserved | unreserved | escaped

So as you can clearly :-) see, fragments are not allowed per the ABNF rules...

---

The new HTTPbis spec had clearer ABNF rules in draft -09, but still only restricted the fragment in ABNF.

At my request, the editors added in -10 [1]:

      Note: Fragments ([RFC3986], Section 3.5) are not part of the
      request-target and thus will not be transmitted in an HTTP
      request.

So hopefully this is clearer now.

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#section-4.1.2

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Stanek
Sent: Monday, August 02, 2010 6:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

On Sun, Aug 1, 2010 at 10:47 PM, Oleg Gryb <[email-masked]> wrote:
I've just verified Ruby and Perl's user agents as well: both worked as expected - no fragments in the web log files. It adds confidence. Thanks to everyone who has answered.

I just verified that the Python urllib client does send the fragment to the server. I've created a patch and will be created a bug on the Python tracker.

Does anyone know what RFC actually talks about not sending the fragment? I've seen 3986 where it explains that a fragment isn't really a part of the URI, but it's doesn't specifically say that the client should not send it to the server.

---

From: Brian Eaton <[email-masked]>
Date: Mon, 2 Aug 2010 23:17:09 -0700

On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb <[email-masked]> wrote:
> fragment, I've read both your proposal for changing  v.9 and the current
> v.10, but still don't understand why we need access_token in a fragment.

Question: why are you implementing the user-agent flow?

> I think, a safer solution would be to return an access token in a response
> form, not in Location header. This way, we'll avoid problems with user
> agents that David Stanek described and prevent browsers from storing tokens
> in a browser's history.

This is nuts.  It would completely break all of the use cases the
user-agent flow was designed to address.

For example, let's say you want to allow third-party site
thirdparty.com to embed some javascript from serviceprovider.com.

The javascript should be able to:
- redirect the user to serviceprovider.com, where serviceprovider.com
can get user consent to share data if necessary.
- receive an access token back from serviceprovider.com.
- use the access token from thirdparty.com to fetch data from
serviceprovider.com.
- do all of the above without server-side code at thirdparty.com.
- do all of the above with as few client <-> server round trips as possible.

The user-agent profile allows that.  If that's not your use case, then
you probably shouldn't be using the user-agent profile at all.

Cheers,
Brian

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 3 Aug 2010 09:00:20 -0700

On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb <[email-masked]> wrote:
> Brian,
>
> I think, it's not so much about browsers written in Python, as about
> automation (crawler) that somebody might want to use.

The User-Agent profile cannot be used by crawlers, the end user needs
to be present to approve. An autonomous client profile would work in
this case, see section 1.4.4.

Marius

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 3 Aug 2010 09:09:23 -0700 (PDT)

----- Original Message ----
> To: Oleg Gryb <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, August 3, 2010 9:00:20 AM
> to be present to approve. 

Why? There are crawlers that can do approval/authentication by providing 
credentials in a request, e.g. when you want to trade stocks at ameritrade.com, 
you usually need to provide creds, but if you're too lazy to do that, you can 
write a crawler that will do it for you. The examples are numerous and very 
common for the user agents written in P/R languages. Regarding AOuth, I can 
envision the following scenario: log to Facebook, select photos, request 
Facebook to print those photos at printig.com

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 3 Aug 2010 09:59:59 -0700 (PDT)

> Question: why are you implementing the user-agent  flow?

It's not helpful. Doesn't answer the qs.

> This is  nuts.  

That's what I thought when was reading User Agent Flow in v.10, but I didn't 
voice it, because wanted to be polite to the authors. My opinion didn't change 
much after this discussion, but it probably will, after I get my answers (see 
below).

>It would completely break all of the use cases the

Please provide an example of code that you would put to thirdparty.com and that 
would not break the use cases. Please also provide an example of response from 
serviceprovider.com with an access token in it (wherever it is - as I understand 
you want to put it to the Location header, but probably I'm wrong).

> - do all of  the above without server-side code at thirdparty.com.

Is it a requirement/use case? Where is it written in the spec? What if 
thirdparty.com generates that JavaScript on the server and returns in a 
response? Would it be a violation of the protocol? If it would, do you want to 
require only static content containing that script at thirdparty.com?

> - do all of the above  with as few client <-> server round trips as possible.

When it comes to an authentication and communication protocols, security is more 
important than an extra round trip in my view, otherwise people would never use 
SSL, which is very inefficient from performance point of view. Also, until I see 
the code that I've asked for above, I won't understand how that "fragment" 
solution will reduce the number of trips.

We can see from this discussion so far that:

1. You don't know how many user agents are out there that would send the 
fragment with the token in a request.
2. It's not clear if that "replace" function will be sufficient to clear 
browser's history in numerous browsers and their versions.

These are still valid security concerns.

Best,
Oleg.

---

From: John Kemp <[email-masked]>
Date: Tue, 3 Aug 2010 13:24:19 -0400

On Aug 2, 2010, at 11:31 PM, Brian Eaton wrote:

> Cool, but this doesn't seem relevant to the user-agent profile.  Market penetration of browsers written in python is limited.
>  
> No idea.  This might be one of those things that all the browsers implement, but has never been fully specified.

It's actually the HTTP specification which fully defines the use of HTTP URIs, and their syntax: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2

The HTTP specification of URIs does not include the fragment component present in the generic URI specification.

So, according to the URI specification, a URI can (generically) contain a fragment.

HTTP URIs should not, when participating in the HTTP protocol, send the fragment, as this is not included in HTTP implementation parsing of the URI (according to the specification).

The fragment ID's use is then also dependent of the MIME type in use. This allows HTML to define the usage of fragments that we're all so familiar with (as internal links within a retrieved HTML document). 

For HTTP implementations though, the fragment ID should clearly NOT be sent, and if it is, that's a bug. 

Regards,

- johnk

> 
> There are a few notes on referers in the browsersec wiki: http://code.google.com/p/browsersec/wiki/Part1
> 
> Cheers,
> Brian

---

From: Brian Eaton <[email-masked]>
Date: Tue, 3 Aug 2010 10:32:04 -0700

> It's not helpful. Doesn't answer the qs.

The reason I asked is because I suspect you are trying to use the
user-agent flow in a way very different from other people.

It's important to choose the right tool for the right job.

Given that you are writing lots of server-side code, you should
probably be looking at the web server flow, not the user-agent flow.

> would not break the use cases.

Take a look at the facebook APIs, in particular the cross-domain
communication schemes:

http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Channel

> Please also provide an example of response from

HTTP/1.1 302 Moved Temporarily

Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345

rpc_relay.html is highly cached in the browser, so instead of
incurring hundreds of ms to fetch a file, the data lands in the
third-party.com javascript in under a millisecond.

> Is it a requirement/use case?

Yes, it's a requirement.

> Where is it written in the spec?

Hopefully the spec will start adding more language around specific use
cases to guide developers in picking which profiles they want to use.

> What if
> response? Would it be a violation of the protocol?

It would not be a violation of the protocol.  It would be inefficient.

> SSL, which is very inefficient from performance point of view.

SSL inefficiency is largely mythical:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html.

> Also, until I see

HTH.

If this hasn't been helpful, you want want to run up firebug and visit
a web site like iGoogle.  Watch the number of requests triggered in
the browser, and watch how many are served from cache.

Cheers,
Brian

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 3 Aug 2010 10:33:42 -0700 (PDT)

----- Original Message ----
> From: John Kemp <[email-masked]>
> To: Brian Eaton <[email-masked]>
> Sent: Tue, August 3, 2010 10:24:19 AM
> HTTP URIs should not, when  participating in the HTTP protocol, send the 
>fragment, as this is not included  in HTTP implementation parsing of the URI 
>(according to the  specification).

That's interesting, so if somebody puts a fragment to Location header, which is 
a part of HTTP protocol, it will be a violation of the protocol and can be 
considered as a server side bug?

See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.

 Location       = "Location" ":" absoluteURI

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 3 Aug 2010 10:39:02 -0700

Fragments are perfectly valid in the Location header URI:

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Oleg Gryb
> Sent: Tuesday, August 03, 2010 10:34 AM
> To: John Kemp; Brian Eaton
> Cc: [email-masked]
> > HTTP URIs should not, when  participating in the HTTP protocol, send
> >the fragment, as this is not included  in HTTP implementation parsing
> >of the URI (according to the  specification).
> 
> That's interesting, so if somebody puts a fragment to Location header, which
> is a part of HTTP protocol, it will be a violation of the protocol and can be

---

From: John Kemp <[email-masked]>
Date: Tue, 3 Aug 2010 13:51:09 -0400

Yes, that's correct, as HTTP adopts the definition of 'absoluteURI' from the URI specification itself. It's just in the protocol itself that fragments are not sent.

From RFC2616: "This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification" (where 'that' refers to RFC2396). It then proceeds to restrict URIs used in the HTTP scheme itself as being:

http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Fragments are not valid in the protocol itself, but they often are elsewhere (depending on the usage, and which specifications apply). As Eran says, they are perfectly valid in a Location HTTP header.

Regards,

- johnk

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 3 Aug 2010 11:44:26 -0700 (PDT)

----- Original Message ----
> To: Eran Hammer-Lahav <[email-masked]>
> Cc: Oleg Gryb <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tue, August 3, 2010 10:51:09 AM
> Yes, that's correct, as HTTP adopts the definition of 'absoluteURI' from the 
>URI  specification itself. It's just in the protocol itself that fragments are 
>not  sent.
> 
> From RFC2616: "This specification adopts the definitions of  "URI-reference", 
>"absoluteURI", "relativeURI", "port", "host","abs_path",  "rel_path", and 
>"authority" from that specification" (where 'that' refers to  RFC2396). It then 
>proceeds to restrict URIs used in the HTTP scheme itself as  being:
> 
> Fragments are not valid in the protocol itself, but they often are  elsewhere 
>(depending on the usage, and which specifications apply). As Eran  says, they 
>are perfectly valid in a Location HTTP  header.

Definition of absoluteURI in RFC2396 doesn't include fragment. Fragment is 
explicitly defined in URI-reference only.

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

If authors wanted to have fragment in absoluteURI, why would they use the syntax 
above for URI-reference?

Location header is not defined through URI-reference, it's defined through 
absoluteURI in the current version of RFC2616:

The only puzzle for me is the definition and example that Eran has provided at 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4

It's a draft though, where absoluteURI in Location header definition was 
replaced with URI-reference, so Location header has been redefined as follows:

Location       = "Location" ":" OWS Location-v
    Location-v     = URI-reference

The draft will replace RFC2616 IF approved. Until then, fragments in Location 
header should be considered as HTTP protocol violation, I think.

Changing definitions retrospectively in the existing protocol looks like a bad 
idea: it can break some HTTP clients that expect absouteURI in Location,  but 
it's a topic for a different discussion.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Aug 2010 22:44:58 +0300

On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote:

Please provide an example of code that you would put to thirdparty.com<http://thirdparty.com> and that
would not break the use cases.

So if the browser works correctly (instead of what the python library does, then thirdparty.com<http://thirdparty.com> sees only "GET rpc_relay.html", while the javascript also gets the "access_token=12345".

What I'm not getting is why this matters. Is this supposed to be about security?  It can't be any good at that, because the javascript is coming from thirdparty.com<http://thirdparty.com>. If the good people at thirdparty.com<http://thirdparty.com> want to know the access token, they can make their javascript send it to them.  So what is the purpose of this funky use of HTTP? Is the access token a secret? From who?

I thought to look in the Security Considerations section, but that is still TBD, which can be considered worrying at this stage. What assumptions can be made security-wise of each participant really has to be spelled out better.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 3 Aug 2010 13:18:47 -0700

On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir <[email-masked]> wrote:
> So if the browser works correctly (instead of what the python library does,
> then thirdparty.com sees only "GET rpc_relay.html", while the javascript
> also gets the "access_token=12345".
> What I'm not getting is why this matters. Is this supposed to be about
> security?  It can't be any good at that, because the javascript is coming
> from thirdparty.com. If the good people at thirdparty.com want to know the
> access token, they can make their javascript send it to them.  So what is
> the purpose of this funky use of HTTP? Is the access token a secret? From
> who?

Passing the access toke through the URL is insecure and prone to
leaking. If in the query string then the access token my leak through:
- log files, web server at thirdparty.com and any number of proxies
- browser history
- referer header

Putting the access token into the fragment, and also using JavaScript
to clean the URL as soon as the token is extracted, mitigates most of
these issues.

Marius

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Aug 2010 23:28:42 +0300

On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote:

> leaking.

Insecure against what? Prone to leaking of what to whom?

> If in the query string then the access token my leak through:

You're counting a lot on the javascript. That Javascript is coming from thirdparty.com. So we have to assume both trustworthiness and competence of the people in thirdparty.

> to clean the URL as soon as the token is extracted, mitigates most of

I think a security considerations section (different for each profile) is desperately needed.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 3 Aug 2010 13:38:50 -0700

> You're counting a lot on the javascript. That Javascript is coming from thirdparty.com. So we have to assume both trustworthiness and competence of the people in thirdparty.

Yes, definitely, thirdparty.com must be trusted, it is the client that
the end user is authorizing.

> I think a security considerations section (different for each profile) is desperately needed.

True.

Marius

---

From: Brian Eaton <[email-masked]>
Date: Tue, 3 Aug 2010 13:45:18 -0700

Yoav -

You can take a look at this as a starting point:

http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf

---

From: Brian Eaton <[email-masked]>
Date: Tue, 3 Aug 2010 13:47:33 -0700

> also gets the "access_token=12345".

In the average case, thirdparty.com doesn't even see GET
/rpc_relay.html.  The page is cached in the browser.

So the access_token has moved from serviceprovider.com to
thirdparty.com, where javascript on thirdparty.com can use it.

> the purpose of this funky use of HTTP?

It is in large part a performance optimization.

If you pass the token through a server, it adds hundreds of
milliseconds to the request.

If you pass the token entirely on the client, it is under a millisecond.

> Is the access token a secret? From who?

If you aren't sure about this, you don't want OAuth.

---

From: John Kemp <[email-masked]>
Date: Tue, 3 Aug 2010 17:23:49 -0400

> explicitly defined in URI-reference only.

Yes. you're right. My mistake.

> absoluteURI in the current version of RFC2616:

And I guess that actually the URI spec itself has been updated since RFC2616 (see RFC3986) and now has the fragment part included in the generic syntax ;)

> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4

Yes, this draft references RFC3986...

> it's a topic for a different discussion.

Well, things are a bit confusing, certainly, but it seems to me that

a) in 2616bis, fragment in Location seems to be explicitly legal
b) in 2616, it is not, but if, for example, an implementation were attempting to conform to both the newer URI spec (RFC3986) and RFC2616, there might be confusion, but the fragment might well be parsed anyway, depending on the implementation I would guess. 

- johnk

---

From: Oleg Gryb <[email-masked]>
Date: Tue, 3 Aug 2010 15:06:01 -0700 (PDT)

----- Original Message ----

> And I guess that actually the URI spec itself has been  updated since RFC2616 
>(see RFC3986) and now has the fragment part included in  the generic syntax ;)

I don't see it in RFC3986:

absolute-URI  = scheme ":" hier-part [ "?" query ]

Where is the fragment? The answer is: it's still in URI-reference:

URI-reference = URI / relative-ref
relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

> a) in 2616bis, fragment in Location seems to be  explicitly legal

Unlike RFC2616, 2616bis is still a draft, right?
> b) in 2616, it is not, but if, for example, an  implementation were attempting 
>to conform to both the newer URI spec (RFC3986)  and RFC2616, there might be 
>confusion, but the fragment might well be parsed  anyway, depending on the 
>implementation I would guess. 
>
> 

I don't understand why they didn't bump the HTTP version in 2616bis. Apparently, 
they've changed the definition of  very important HTTP header. If existing HTTP 
clients implement strict syntax validation for the response header, they can 
easily fail with the new syntax. 

I think, the right approach would be to declare 2616bis as HTTP 2.0 and state in 
OAuth 2.0 specification that it works with HTTP 2.0 only (if we really can't get 
rid of passing access token in a URL's fragment). Otherwise it's very confusing. 

> >>>> That's  interesting, so if somebody puts a fragment to  Location header,  

> >> which
> >>>> is a part of HTTP  protocol, it will be a violation of the  protocol and 
>can 
>
> >>  be

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 3 Aug 2010 22:26:44 -0700

The HTTPbis WG is tasked with cleaning up the HTTP 1.1 specification and making corrections where needed to reflect how the protocol is actually deployed. Allowing fragments in the Location header is one such adjustment.

HTTPbis is considered the authority on HTTP and even though the work is still a draft, OAuth will align itself with it because that is the best reflection of current IETF thinking. Note that this isn't new. RFC 2616 replaced 2068 which also defined HTTP 1.1 and made changes as well as dropped features due to lack of deployment experience (e.g Link header, LINK and UNLINK methods).

Standards are not the word of god, just the best reflection of how interop is best accomplished in practice.

EHL

> Sent: Tuesday, August 03, 2010 3:06 PM
> To: John Kemp
> Cc: [email-masked]
> > And I guess that actually the URI spec itself has been  updated since
> >RFC2616 (see RFC3986) and now has the fragment part included in  the
> >generic syntax ;)
> 
> > b) in 2616, it is not, but if, for example, an  implementation were
> >attempting to conform to both the newer URI spec (RFC3986)  and
> >RFC2616, there might be confusion, but the fragment might well be
> >parsed  anyway, depending on the implementation I would guess.
> >
> >
> 
> I don't understand why they didn't bump the HTTP version in 2616bis.
> Apparently, they've changed the definition of  very important HTTP header.
> If existing HTTP clients implement strict syntax validation for the response
> header, they can easily fail with the new syntax.
> 
> 
> I think, the right approach would be to declare 2616bis as HTTP 2.0 and state
> in OAuth 2.0 specification that it works with HTTP 2.0 only (if we really can't
> get rid of passing access token in a URL's fragment). Otherwise it's very
> confusing.
> 
> 
> 
> 
> 
> 
> > >> - johnk
> > >>
> > >>>>> the fragment, as this  is  not included  in HTTP implementation
> > >>>>> parsing of the  URI  (according to the  specification).
> > >>>>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 8 Aug 2010 11:10:07 +0300

Looks good, except for two things.

- The user agent profile, that is the subject of this thread is not there.
- I'm missing the part about what we need to trust each party to do. For example, we trust thirdparty.com to provide a javascript that only sends the token to the resource provider, not to any other party, and not even to thirdparty.com itself.

There's the whole question of who I trust to keep my passwords safe, who I trust with temporary access to a resource, and who I trust with long-term access to a resource.

On Aug 3, 2010, at 11:45 PM, Brian Eaton wrote:

> Scanned by Check Point Total Security Gateway.