Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

John and Oleg, good point. I missed that. So in this case the "web-hosted
client resource" is a party different from the RS and is also different
from AS and is not supposed to access to AT. But I guess this "web-hosted
client resource" must be trusted, since its JS has access the the AT on the
browser side anyways.

Maybe the secure way is to let the AS return an HTML with embedded JS and
AT. It does make the AS do more work, but it cuts out the need of
"web-hosted client resource".

Comments?

-- Liyu

On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb  wrote:

> As John has already pointed out - you're confusing RS with the web-hosted
> client resource.
>
>
> --
> *From:* Liyu Yi 
> *To:* John Bradley 
> *Cc:* Oleg Gryb ; "" 
> *Sent:* Friday, July 1, 2016 6:11 PM
>
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> I would say AT is supposed to be consumed by the Resource Server. Although
> the original spec does not show how AT is used by the client, but the AT
> will be sent out, most likely by the browser directly, or in a rare case if
> the client application has another channel, indirectly.
>
> The fact is that the AT is not sent in the 1st GET request does leave the
> RS JavaScript a chance to choose the right method, say an ajax POST. But AT
> is NOT  a secrete to RS.
>
>
>
>
> On Fri, Jul 1, 2016 at 5:53 PM, John Bradley  wrote:
>
> yes
>
> On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
>
> I think, the intention was not to share AT with the web-hosted client
> resource. As you can see in the original flow the latter never receives the
> AT, it simply provides code that can get AT from a fragment and some UI. In
> the modified flow AT is sent to the web-hosted client resource, which makes
> security worse in my view, because you have your AT exposed in two places
> now - in the User Agent *and* in the web-hosted client resource.
>
>
>
> ------------------
> *From:* John Bradley 
> *To:* Liyu Yi 
> *Cc:* Oleg Gryb ; "" 
> *Sent:* Friday, July 1, 2016 4:06 PM
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> I take it that Web-hosted client resource is part of the client.
>
> I think perhaps you have client and resource serve r mixed up a bit in
> your diagram.
>
> Yes you could do that but it is not a great way to build the client as it
> will blow away context.
> You can do it but people generally want to start the application in the
> browser first and then call out to the IdP  in a iFrame.
>
> What you propose would work more or less.  I don’t see it as a pattern
> that I would necessarily recommend over the current fragment encoding.
>
> If we mover to post message it would include API  for logout and session
> management, not just login.
>
> John B.
>
>
> On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
>
> Understood there is an Authorization Code grant type; here I am more
> focusing on the Implicit grant type.
>
> also when I mentioned POST, I did not mean postMessage, it is simply the
> HTTP POST. Specifically it is more like this ...
>
>
>
> 4.2 <https://tools.ietf.org/html/rfc6749#section-4.2>. Implicit Grant
> (modified)
>
>  +--+
>  | Resource |
>  |  Owner   |
>  |  |
>  +--+
>   ^
>   |
>  (B)
>  +|-+  Client Identifier +---+
>  | -+(A)-- & Redirection URI --->|   |
>  |  User-   || Authorization |
>  |  Agent  -|(B)-- User authenticates -->| Server|
>  |  ||   |
>  |  |<---(C)- Response embedded JS -<|   |
>  |  |  with Access Token +---+
>  |  |in JS content, which will be posted to Resource 
> Server
>  |  |+---+
>  |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
>  |  | with Access Token  | Client|
>  |  ||Resource   |
>  | (F)  |<---(E)- RS Script <|   |
>  |  | with Access Token  +---+
>  +-|+
>||
>   (A)  (G) Access Token
>||
>^v
>  +-+
>  | |
>  |  Client |
>  | |
>  +-+
>
>
>
>Figure 4:

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

 supports web server clients at the moment.   That might
>>>>> change in future to support native apps if that an be made to support the
>>>>> security requirements of Heath IT.
>>>>>
>>>>> So the thing HTTP POST responses won’t work well for is a type of in
>>>>> browser single page OAuth client.  That still needs fragment encoded
>>>>> responses or the new post-message Java Script API approach.
>>>>>
>>>>> John B.
>>>>>
>>>>>
>>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
>>>>>
>>>>> Thanks Justin,
>>>>>
>>>>> To clarify: John's comment and my question were about POST. (I do
>>>>> understand the behavior of HTTP POST and of window.postMessage; these are
>>>>> totally different things.) From my perspective in SMART Health IT, we use
>>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>>>> authorization
>>>>> spec <http://docs.smarthealthit.org/authorization/> even for public
>>>>> clients, and it has worked very well for us, with about a dozen electronic
>>>>> health record servers supporting this approach. That's why I was curious 
>>>>> to
>>>>> hear John's perspective about limitations.
>>>>>
>>>>>   -J
>>>>>
>>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:
>>>>>
>>>>>> > POST will send things to the server, which isn’t desirable if your
>>>>>> client is solely in the browser
>>>>>> Why it's not desirable, assuming that we disregard performance? You
>>>>>> can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong
>>>>>> with this?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *From:* Justin Richer 
>>>>>> *To:* Josh Mandel 
>>>>>> *Cc:* Oleg Gryb ; "" ;
>>>>>> Liyu Yi 
>>>>>> *Sent:* Friday, July 1, 2016 2:00 PM
>>>>>>
>>>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as
>>>>>> Implicit grant
>>>>>>
>>>>>> POST will send things to the server, which isn’t desirable if your
>>>>>> client is solely in the browser. postMessage is a browser API and not to 
>>>>>> be
>>>>>> confused with HTTP POST. postMessage messages stay (or can stay) within 
>>>>>> the
>>>>>> browser, which is the intent here.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:
>>>>>>
>>>>>> John,
>>>>>>
>>>>>> Could you clarify what you mean by "POST doesn't really work"? Do
>>>>>> you just mean that CORS support (e.g., http://caniuse.com/#feat=cors)
>>>>>> isn't universal, or something more?
>>>>>>
>>>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley 
>>>>>> wrote:
>>>>>>
>>>>>> Yes but POST doesn't really work for in browser apps.
>>>>>>
>>>>>> If it is a server app it should be using the code flow with GET or
>>>>>> POST as you like.
>>>>>>
>>>>>> If we do a  post message based binding it will be targeted at in
>>>>>> browser applications.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:
>>>>>>
>>>>>> BTW, I do not see any significant performance concerns for post.
>>>>>> Parsing and executing the Javascript logic for post operation will be on
>>>>>> the client side, no extra server load is introduced.
>>>>>>
>>>>>> Plus post will remove the size restriction of the URL length.
>>>>>>
>>>>>> -- Liyu
>>>>>>
>>>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>>>>>>
>>>>>> Thanks for the great comments and advices.
>>>>>>
>>>>>> I think it is a good idea for the working group to revise the
>>>&

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

I would say AT is supposed to be consumed by the Resource Server. Although
the original spec does not show how AT is used by the client, but the AT
will be sent out, most likely by the browser directly, or in a rare case if
the client application has another channel, indirectly.

The fact is that the AT is not sent in the 1st GET request does leave the
RS JavaScript a chance to choose the right method, say an ajax POST. But AT
is NOT  a secrete to RS.




On Fri, Jul 1, 2016 at 5:53 PM, John Bradley  wrote:

> yes
>
> On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
>
> I think, the intention was not to share AT with the web-hosted client
> resource. As you can see in the original flow the latter never receives the
> AT, it simply provides code that can get AT from a fragment and some UI. In
> the modified flow AT is sent to the web-hosted client resource, which makes
> security worse in my view, because you have your AT exposed in two places
> now - in the User Agent *and* in the web-hosted client resource.
>
>
>
> --
> *From:* John Bradley 
> *To:* Liyu Yi 
> *Cc:* Oleg Gryb ; "" 
> *Sent:* Friday, July 1, 2016 4:06 PM
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> I take it that Web-hosted client resource is part of the client.
>
> I think perhaps you have client and resource serve r mixed up a bit in
> your diagram.
>
> Yes you could do that but it is not a great way to build the client as it
> will blow away context.
> You can do it but people generally want to start the application in the
> browser first and then call out to the IdP  in a iFrame.
>
> What you propose would work more or less.  I don’t see it as a pattern
> that I would necessarily recommend over the current fragment encoding.
>
> If we mover to post message it would include API  for logout and session
> management, not just login.
>
> John B.
>
>
> On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
>
> Understood there is an Authorization Code grant type; here I am more
> focusing on the Implicit grant type.
>
> also when I mentioned POST, I did not mean postMessage, it is simply the
> HTTP POST. Specifically it is more like this ...
>
>
>
> 4.2 <https://tools.ietf.org/html/rfc6749#section-4.2>. Implicit Grant
> (modified)
>
>  +--+
>  | Resource |
>  |  Owner   |
>  |  |
>  +--+
>   ^
>   |
>  (B)
>  +|-+  Client Identifier +---+
>  | -+(A)-- & Redirection URI --->|   |
>  |  User-   || Authorization |
>  |  Agent  -|(B)-- User authenticates -->| Server|
>  |  ||   |
>  |  |<---(C)- Response embedded JS -<|   |
>  |  |  with Access Token +---+
>  |  |in JS content, which will be posted to Resource 
> Server
>  |  |+---+
>  |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
>  |  | with Access Token  | Client|
>  |  ||Resource   |
>  | (F)  |<---(E)- RS Script <|   |
>  |  | with Access Token  +---+
>  +-|+
>||
>   (A)  (G) Access Token
>||
>^v
>  +-+
>  | |
>  |  Client |
>  | |
>  +-+
>
>
>
>Figure 4: Implicit Grant Flow
>
>
>The flow illustrated in Figure 4 includes the following steps:
>
>(A)  The client initiates the flow by directing the resource owner's
> user-agent to the authorization endpoint.  The client includes
> its client identifier, requested scope, local state, and a
> redirection URI to which the authorization server will send the
> user-agent back once access is granted (or denied).
>
>(B)  The authorization server authenticates the resource owner (via
> the user-agent) and establishes whether the resource owner
> grants or denies the client's access request.
>
>(C)  Assuming the resource owner grants access, the authorization
> server responds with a JavaScript logic which automatically posts to
> "redirection" URI provided earlier.  The JavaScript includes
> the access token in the URI fragment.
>
>(D)  The user-agent does

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

BTW, I do not see any significant performance concerns for post. Parsing
and executing the Javascript logic for post operation will be on the client
side, no extra server load is introduced.

Plus post will remove the size restriction of the URL length.

-- Liyu

On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:

> Thanks for the great comments and advices.
>
> I think it is a good idea for the working group to revise the fragment
> part in the spec, since there might be public available tools already
> implemented this approach and people can end up with a solution with
> serious security loopholes.
>
> The re-append issue can be mitigate by a logic on Resource Server which
> carefully re-writes/removes the fragment in any redirect, if the the
> redirect can not be avoided.
>
> -- Liyu
>
>
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
>
>> This behaviour started changing around 2011
>>
>> From HTTP/1.1
>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>>   f the Location value provided in a 3xx (Redirection) response does
>>
>>not have a fragment component, a user agent MUST process the
>>redirection as if the value inherits the fragment component of the
>>URI reference used to generate the request target (i.e., the
>>redirection inherits the original reference's fragment, if any).
>>
>>For example, a GET request generated for the URI reference
>>"http://www.example.org/~tim"; might result in a 303 (See Other)
>>response containing the header field:
>>
>>  Location: /People.html#tim
>>
>>which suggests that the user agent redirect to
>>"http://www.example.org/People.html#tim”
>>
>>
>>Likewise, a GET request generated for the URI reference
>>"http://www.example.org/index.html#larry"; might result in a 301
>>(Moved Permanently) response containing the header field:
>>
>>  Location: http://www.example.net/index.html
>>
>>which suggests that the user agent redirect to
>>"http://www.example.net/index.html#larry";, preserving the original
>>fragment identifier.
>>
>>
>>
>> This blog also explores the change.
>>
>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>>
>>
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>>
>> "Browsers now re-append  fragments across 302 redirects unless they are
>> explicitly cleared this makes fragment encoding less safe than it was  when
>> originally specified" - thanks Jim. Looks like a good reason for vetting
>> this flow out.
>>
>> John,
>> Please provide more details/links about re-appending fragments.
>>
>> Thanks,
>> Oleg.
>>
>>
>> --
>> *From:* Jim Manico 
>> *To:* Oleg Gryb 
>> *Cc:* "oauth@ietf.org" ; Liyu Yi 
>> *Sent:* Thursday, June 30, 2016 10:25 PM
>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
>> grant
>>
>> Oleg! Hello! Great to see you pop up here with a similar concern.
>>
>> John Bradley just answered this thread with the details I was looking for
>> (thanks John, hat tip your way).
>>
>> He also mentioned details about fragment leakage:
>>
>> "Browsers now re-append  fragments across 302 redirects unless they are
>> explicitly cleared this makes fragment encoding less safe than it was when
>> originally specified"
>>
>> Again, I'm new here but I'm grateful for this conversation.
>>
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>>
>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:
>>
>> We've discussed access tokens in URI back in 2010 (
>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html).
>> There were two major objectives when I was saying that it's not secure:
>>
>> 1. Fragment is not sent to a server by a browser. When I've asked if this
>> is true for every browser in the world, nobody was able to answer.
>> 2. Replacing with POST would mean a significant performance impact in
>> some high volume implementations (I think it was Goole folks who were
>> saying this, but I don't remember now).
>>
>> AFAIR, nobody was arguing about browsing history, so it's valid.
>>
>> So, 6 years later we're at square one with this and I hope that this time
>> the community will be more successful with getting rid of secrets in URL.
>>
>> BTW, Jim, if you can co

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

For Jim's comment

"HTTP POST requests are also a lot more difficult to cache server side
compared to URI's which are easier to cache. I'm likely not explaining this
well, but I believe it's a webscale concern."

I would say, most of the OAuth case will be using HTTPS.  and caching with
HTTPS is only possible at the end point where SSL/TLS is terminated. when
it goes to the server side, it is all about turning the post data to the
cache key,  some logic is required, but does this have a serious
performance issue?

However, I do realized that if fetching the resource is implemented as a
POST, the POST response is typically not cached. For this, we might be able
to use the POST to establish HTTP session and then use the GET to fetch the
resource, and with right logic to control the caching behavior. BTW,
caching itself also has security implication.


On Fri, Jul 1, 2016 at 3:44 PM, Oleg Gryb  wrote:

> I'm aware about exploits related to improper redirect_url validation,
> which was FB case, no qs here,  but I still can't understand if appending a
> fragment to Location by a browser makes this exploit simpler or can lead to
> other exploits that have not been described yet.
>
>
> --
> *From:* John Bradley 
> *To:* Oleg Gryb 
> *Cc:* "oauth@ietf.org" ; Liyu Yi 
> *Sent:* Friday, July 1, 2016 2:21 PM
>
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> If the attacker can modify the redirect URI to anything like an embedded
> add that will do a 302 redirect then the recipient of the redirect can load
> JS to extract the access token.
>
> This has happened at Facebook so many times I have lost count.   It is not
> theoretical, it happens all the time.
> One reason you need to do exact redirect_uri matching in the AS but people
> are not so good at following that and take redirects to any URI on the host
> in some cases.
>
> When used correctly for a real in web client it is fine.  For a web server
> client it introduces unnecessary risks over the code flow, or hybrid flow
> using POST.
>
> Others may differ with my opinion.
>
> John B.
>
> On Jul 1, 2016, at 4:52 PM, Oleg Gryb  wrote:
>
> John,
>
> Thanks, very useful. However, I'm still trying to figure out why it's
> dangerous. Fragment doesn't travel to a server in this new flow either.
> Appending it to Location header is done by the browser who needs to
> memorize what the original request was. If the original request had a
> fragment and the browser got redirected, Location header will be appended
> by the browser.
>
> Are you saying that this is dangerous because the browser would *always*
> need to store the fragment somewhere in its memory just in case if a server
> decides to redirect?
>
> So an attack vector here is that an imposter can try to retrieve the
> fragment from the browser's memory somehow. Is my understanding correct?
>
> Oleg.
>
>
> --
> *From:* John Bradley 
> *To:* Oleg Gryb 
> *Cc:* "oauth@ietf.org" ; Liyu Yi 
> *Sent:* Friday, July 1, 2016 11:33 AM
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> This behaviour started changing around 2011
>
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>   f the Location value provided in a 3xx (Redirection) response does
>
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
>
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim"; might result in a 303 (See Other)
>response containing the header field:
>
>  Location: /People.html#tim
>
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim”
>
>
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry"; might result in a 301
>(Moved Permanently) response containing the header field:
>
>  Location: http://www.example.net/index.html
>
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry";, preserving the original
>fragment identifier.
>
>
>
> This blog also explores the change.
>
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>
>
> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>
> "Browsers now re-append  

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

wrote:
>>
>> I think the confusion here is that I'm not using HEART's OAuth profiles
>> :-)
>>
>> I'm using the SMART profiles, where we do specify the use of an
>> authorization code grant even for browser-based public clients (in which
>> case, no client_secret is issued or used). I'm just trying to understand
>> your perspective eon why this "won't work well". Perhaps you didn't mean
>> this comment to refer to browser-based OAuth clients generally?
>>
>>   -Josh
>>
>> On Fri, Jul 1, 2016 at 5:45 PM, John Bradley  wrote:
>>
>>> I don’t think the post response mode is supported by heart so I suspect
>>> that we are talking about different things.
>>>
>>> You are probably using the supported code flow that uses a 302 get to
>>> return the code to the OAuth client on the server.
>>> The Web server is then acting as a confidential client to exchange the
>>> code via a POST (different POST) with the AS token_endpoint.
>>>
>>> The Token endpoint will return a access token (AT) and optional refresh
>>> token (RT).
>>>
>>> The web page may be getting the server to make the OAuth calls on it’s
>>> behalf to the Resource Server, or possibly you are passing the AT from the
>>> server back to a Java script app that is using CORES to make calls directly
>>> to the RS without going through the Web server.
>>>
>>> Passing the AT back to the user agent from the client is not
>>> recommended.
>>>
>>> For in browser clients where the JS is using the AT to make the calls
>>> directly to the RS via CORES the recommended approach is to use the
>>> fragment encoded response via a 302 to deliver the AT directly to the
>>> client (It never hits the backend Web server).
>>>
>>> However I believe In browser OAuth clients are not currently supported
>>> in HEART, so I am not quite sure what you are doing.
>>>
>>> Perhaps Justin has a better answer.
>>>
>>> John B.
>>>
>>>
>>> On Jul 1, 2016, at 5:33 PM, Josh Mandel  wrote:
>>>
>>> John,
>>>
>>> I appreciate your response. I'm hoping you can clarify why you say that
>>> "HTTP POST... won't work well for... [a] single page OAuth client"?
>>>
>>> We commonly build single-page apps that act as OAuth clients for SMART
>>> (e.g. this sample app
>>> <https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
>>>  ),
>>> and we've had good experience with the technique. Could you elaborate?
>>>
>>>   -J
>>>
>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley  wrote:
>>>
>>>> HEART only supports web server clients at the moment.   That might
>>>> change in future to support native apps if that an be made to support the
>>>> security requirements of Heath IT.
>>>>
>>>> So the thing HTTP POST responses won’t work well for is a type of in
>>>> browser single page OAuth client.  That still needs fragment encoded
>>>> responses or the new post-message Java Script API approach.
>>>>
>>>> John B.
>>>>
>>>>
>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
>>>>
>>>> Thanks Justin,
>>>>
>>>> To clarify: John's comment and my question were about POST. (I do
>>>> understand the behavior of HTTP POST and of window.postMessage; these are
>>>> totally different things.) From my perspective in SMART Health IT, we use
>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>>> authorization
>>>> spec <http://docs.smarthealthit.org/authorization/> even for public
>>>> clients, and it has worked very well for us, with about a dozen electronic
>>>> health record servers supporting this approach. That's why I was curious to
>>>> hear John's perspective about limitations.
>>>>
>>>>   -J
>>>>
>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:
>>>>
>>>>> > POST will send things to the server, which isn’t desirable if your
>>>>> client is solely in the browser
>>>>> Why it's not desirable, assuming that we disregard performance? You
>>>>> can generate HTTP POST from JS, e.g. through an AJAX call. What is wrong
>>>>> with 

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Liyu Yi]

Thanks for the great comments and advices.

I think it is a good idea for the working group to revise the fragment part
in the spec, since there might be public available tools already
implemented this approach and people can end up with a solution with
serious security loopholes.

The re-append issue can be mitigate by a logic on Resource Server which
carefully re-writes/removes the fragment in any redirect, if the the
redirect can not be avoided.

-- Liyu


On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:

> This behaviour started changing around 2011
>
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>   f the Location value provided in a 3xx (Redirection) response does
>
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
>
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim"; might result in a 303 (See Other)
>response containing the header field:
>
>  Location: /People.html#tim
>
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim”
>
>
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry"; might result in a 301
>(Moved Permanently) response containing the header field:
>
>  Location: http://www.example.net/index.html
>
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry";, preserving the original
>fragment identifier.
>
>
>
> This blog also explores the change.
>
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>
>
> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>
> "Browsers now re-append  fragments across 302 redirects unless they are
> explicitly cleared this makes fragment encoding less safe than it was  when
> originally specified" - thanks Jim. Looks like a good reason for vetting
> this flow out.
>
> John,
> Please provide more details/links about re-appending fragments.
>
> Thanks,
> Oleg.
>
>
> --------------
> *From:* Jim Manico 
> *To:* Oleg Gryb 
> *Cc:* "oauth@ietf.org" ; Liyu Yi 
> *Sent:* Thursday, June 30, 2016 10:25 PM
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> Oleg! Hello! Great to see you pop up here with a similar concern.
>
> John Bradley just answered this thread with the details I was looking for
> (thanks John, hat tip your way).
>
> He also mentioned details about fragment leakage:
>
> "Browsers now re-append  fragments across 302 redirects unless they are
> explicitly cleared this makes fragment encoding less safe than it was when
> originally specified"
>
> Again, I'm new here but I'm grateful for this conversation.
>
> Aloha,
> --
> Jim Manico
> @Manicode
>
> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:
>
> We've discussed access tokens in URI back in 2010 (
> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There
> were two major objectives when I was saying that it's not secure:
>
> 1. Fragment is not sent to a server by a browser. When I've asked if this
> is true for every browser in the world, nobody was able to answer.
> 2. Replacing with POST would mean a significant performance impact in some
> high volume implementations (I think it was Goole folks who were saying
> this, but I don't remember now).
>
> AFAIR, nobody was arguing about browsing history, so it's valid.
>
> So, 6 years later we're at square one with this and I hope that this time
> the community will be more successful with getting rid of secrets in URL.
>
> BTW, Jim, if you can come up with other scenarios when fragments can leak,
> please share. It'll probably help the community with solving this problem
> faster than in 6 years.
>
> Thanks,
> Oleg.
>
>
> --
> *From:* Jim Manico 
> *To:* Liyu Yi ; oauth@ietf.org
> *Sent:* Wednesday, June 29, 2016 7:30 AM
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> > Shouldn’t it be more secure if we change to use a post method for
> access token, similar to the SAML does?
> I say yes. But please note I'm very new at this and someone with more
> experience will have more to say or correct my comments.
> Here are a few more details to consider.
> 1) OAuth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

Here is actually some idea. John, please let me know if there is anything wrong 
with this.
1. At step "C" Auth Server instead of serving a redirect will return a payload 
in a response with a JS  called on page load that will do the redirect.
Something like below where I use JsRender, but it can be any HTML renderer 
implemented in JS
function doRedirect() {var redirect_uri = ""; // we got it from 
ASvar data = [    "access_token": "x", // we got it from AS             
                           // other params if needed]$.get(redirect_uri, 
function(response) {  var script = document.createElement('script'); 
script.setAttribute('type', 'text/x-jsrender'); script.id = 'template'; 
script.innerHTML = response;
 var template = $.templates(script); var html = template.render(data); 
$("#result").html(html);});

Template returned from the web hosted client resource should include something 
like this:
      ... other 
params if needed 
The generated page will be rendered in a browser with all params including 
access token provided in hidden fields.
Security risk here is the same - user agent has access to AT, but it's the same 
risk as in the original flow. The benefit - no secrets in URI.



 
  From: Oleg Gryb 
 To: Liyu Yi ; Oleg Gryb  
Cc: "" 
 Sent: Friday, July 1, 2016 6:43 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
You know, I've tried to solve this problem 6 years ago and I failed, but I'm 
glad that community is looking to this again and I hope that John and others 
will eventually come up with something better than what we have now.
If I come up with a sane idea, I'll definitely share.
 

 
  From: Liyu Yi 
 To: Oleg Gryb  
Cc: John Bradley ; "" 
 Sent: Friday, July 1, 2016 6:37 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
John and Oleg, good point. I missed that. So in this case the "web-hosted 
client resource" is a party different from the RS and is also different from AS 
and is not supposed to access to AT. But I guess this "web-hosted client 
resource" must be trusted, since its JS has access the the AT on the browser 
side anyways.
Maybe the secure way is to let the AS return an HTML with embedded JS and AT. 
It does make the AS do more work, but it cuts out the need of "web-hosted 
client resource".
Comments?
-- Liyu
On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb  wrote:

As John has already pointed out - you're confusing RS with the web-hosted 
client resource.

 
      From: Liyu Yi 
 To: John Bradley  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 6:11 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
I would say AT is supposed to be consumed by the Resource Server. Although the 
original spec does not show how AT is used by the client, but the AT will be 
sent out, most likely by the browser directly, or in a rare case if the client 
application has another channel, indirectly.
The fact is that the AT is not sent in the 1st GET request does leave the RS 
JavaScript a chance to choose the right method, say an ajax POST. But AT is NOT 
 a secrete to RS.



On Fri, Jul 1, 2016 at 5:53 PM, John Bradley  wrote:

yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
I think, the intention was not to share AT with the web-hosted client resource. 
As you can see in the original flow the latter never receives the AT, it simply 
provides code that can get AT from a fragment and some UI. In the modified flow 
AT is sent to the web-hosted client resource, which makes security worse in my 
view, because you have your AT exposed in two places now - in the User Agent 
*and* in the web-hosted client resource.


 
  From: John Bradley 
 To: Liyu Yi  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 4:06 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
I take it that Web-hosted client resource is part of the client.
I think perhaps you have client and resource serve r mixed up a bit in your 
diagram.
Yes you could do that but it is not a great way to build the client as it will 
blow away context.  You can do it but people generally want to start the 
application in the browser first and then call out to the IdP  in a iFrame.
What you propose would work more or less.  I don’t see it as a pattern that I 
would necessarily recommend over the current fragment encoding.
If we mover to post message it would include API  for logout and session 
management, not just login.
John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
Understood there is an Authorization Code grant type; here I am more focusing 
on the Implicit grant type.   also when I mentioned POST, I did not mean 
postMessage, it is simply the HTTP POST. Specifically it is more like this ...



4.2. I

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

You know, I've tried to solve this problem 6 years ago and I failed, but I'm 
glad that community is looking to this again and I hope that John and others 
will eventually come up with something better than what we have now.
If I come up with a sane idea, I'll definitely share.
 

 
  From: Liyu Yi 
 To: Oleg Gryb  
Cc: John Bradley ; "" 
 Sent: Friday, July 1, 2016 6:37 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
John and Oleg, good point. I missed that. So in this case the "web-hosted 
client resource" is a party different from the RS and is also different from AS 
and is not supposed to access to AT. But I guess this "web-hosted client 
resource" must be trusted, since its JS has access the the AT on the browser 
side anyways.
Maybe the secure way is to let the AS return an HTML with embedded JS and AT. 
It does make the AS do more work, but it cuts out the need of "web-hosted 
client resource".
Comments?
-- Liyu
On Fri, Jul 1, 2016 at 6:14 PM, Oleg Gryb  wrote:

As John has already pointed out - you're confusing RS with the web-hosted 
client resource.

 
  From: Liyu Yi 
 To: John Bradley  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 6:11 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
I would say AT is supposed to be consumed by the Resource Server. Although the 
original spec does not show how AT is used by the client, but the AT will be 
sent out, most likely by the browser directly, or in a rare case if the client 
application has another channel, indirectly.
The fact is that the AT is not sent in the 1st GET request does leave the RS 
JavaScript a chance to choose the right method, say an ajax POST. But AT is NOT 
 a secrete to RS.



On Fri, Jul 1, 2016 at 5:53 PM, John Bradley  wrote:

yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
I think, the intention was not to share AT with the web-hosted client resource. 
As you can see in the original flow the latter never receives the AT, it simply 
provides code that can get AT from a fragment and some UI. In the modified flow 
AT is sent to the web-hosted client resource, which makes security worse in my 
view, because you have your AT exposed in two places now - in the User Agent 
*and* in the web-hosted client resource.


 
  From: John Bradley 
 To: Liyu Yi  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 4:06 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
I take it that Web-hosted client resource is part of the client.
I think perhaps you have client and resource serve r mixed up a bit in your 
diagram.
Yes you could do that but it is not a great way to build the client as it will 
blow away context.  You can do it but people generally want to start the 
application in the browser first and then call out to the IdP  in a iFrame.
What you propose would work more or less.  I don’t see it as a pattern that I 
would necessarily recommend over the current fragment encoding.
If we mover to post message it would include API  for logout and session 
management, not just login.
John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
Understood there is an Authorization Code grant type; here I am more focusing 
on the Implicit grant type.   also when I mentioned POST, I did not mean 
postMessage, it is simply the HTTP POST. Specifically it is more like this ...



4.2. Implicit Grant (modified)
 +--+
 | Resource |
 |  Owner   |
 |  |
 +--+
  ^
  |
 (B)
 +|-+  Client Identifier +---+
 | -+(A)-- & Redirection URI --->|   |
 |  User-   || Authorization |
 |  Agent  -|(B)-- User authenticates -->| Server|
 |  ||   |
 |  |<---(C)- Response embedded JS -<|   |
 |  |  with Access Token +---+
 |  |in JS content, which will be posted to Resource 
Server
 |  |+---+
 |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
 |  | with Access Token  | Client|
 |  ||Resource   |
 | (F)  |<---(E)- RS Script <|   |
 |  | with Access Token  +---+
 +-|+
   ||
  (A)  (G) Access Token
   ||
   ^v
 +-+
 | |
 |  Client |
 | |
 +-+



   Figure 4: Implicit Grant Flow

   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
 

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

As John has already pointed out - you're confusing RS with the web-hosted 
client resource.

 
  From: Liyu Yi 
 To: John Bradley  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 6:11 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
I would say AT is supposed to be consumed by the Resource Server. Although the 
original spec does not show how AT is used by the client, but the AT will be 
sent out, most likely by the browser directly, or in a rare case if the client 
application has another channel, indirectly.
The fact is that the AT is not sent in the 1st GET request does leave the RS 
JavaScript a chance to choose the right method, say an ajax POST. But AT is NOT 
 a secrete to RS.



On Fri, Jul 1, 2016 at 5:53 PM, John Bradley  wrote:

yes

On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
I think, the intention was not to share AT with the web-hosted client resource. 
As you can see in the original flow the latter never receives the AT, it simply 
provides code that can get AT from a fragment and some UI. In the modified flow 
AT is sent to the web-hosted client resource, which makes security worse in my 
view, because you have your AT exposed in two places now - in the User Agent 
*and* in the web-hosted client resource.


 
  From: John Bradley 
 To: Liyu Yi  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 4:06 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
I take it that Web-hosted client resource is part of the client.
I think perhaps you have client and resource serve r mixed up a bit in your 
diagram.
Yes you could do that but it is not a great way to build the client as it will 
blow away context.  You can do it but people generally want to start the 
application in the browser first and then call out to the IdP  in a iFrame.
What you propose would work more or less.  I don’t see it as a pattern that I 
would necessarily recommend over the current fragment encoding.
If we mover to post message it would include API  for logout and session 
management, not just login.
John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
Understood there is an Authorization Code grant type; here I am more focusing 
on the Implicit grant type.   also when I mentioned POST, I did not mean 
postMessage, it is simply the HTTP POST. Specifically it is more like this ...



4.2. Implicit Grant (modified)
 +--+
 | Resource |
 |  Owner   |
 |  |
 +--+
  ^
  |
 (B)
 +|-+  Client Identifier +---+
 | -+(A)-- & Redirection URI --->|   |
 |  User-   || Authorization |
 |  Agent  -|(B)-- User authenticates -->| Server|
 |  ||   |
 |  |<---(C)- Response embedded JS -<|   |
 |  |  with Access Token +---+
 |  |in JS content, which will be posted to Resource 
Server
 |  |+---+
 |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
 |  | with Access Token  | Client|
 |  ||Resource   |
 | (F)  |<---(E)- RS Script <|   |
 |  | with Access Token  +---+
 +-|+
   ||
  (A)  (G) Access Token
   ||
   ^v
 +-+
 | |
 |  Client |
 | |
 +-+



   Figure 4: Implicit Grant Flow

   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint.  The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
server responds with a JavaScript logic which automatically posts to 
"redirection" URI provided earlier.  The JavaScript includes
the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
user agent can actually do post without the access token  in a 
different iframe,   then use postMessage to pass the token 
over, but I do not see why get it need that compexity.

On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel  wrote:

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

yes
> On Jul 1, 2016, at 8:39 PM, Oleg Gryb  wrote:
> 
> I think, the intention was not to share AT with the web-hosted client 
> resource. As you can see in the original flow the latter never receives the 
> AT, it simply provides code that can get AT from a fragment and some UI. In 
> the modified flow AT is sent to the web-hosted client resource, which makes 
> security worse in my view, because you have your AT exposed in two places now 
> - in the User Agent *and* in the web-hosted client resource.
> 
> 
> 
> From: John Bradley 
> To: Liyu Yi  
> Cc: Oleg Gryb ; "" 
> Sent: Friday, July 1, 2016 4:06 PM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> I take it that Web-hosted client resource is part of the client.
> 
> I think perhaps you have client and resource serve r mixed up a bit in your 
> diagram.
> 
> Yes you could do that but it is not a great way to build the client as it 
> will blow away context.  
> You can do it but people generally want to start the application in the 
> browser first and then call out to the IdP  in a iFrame.
> 
> What you propose would work more or less.  I don’t see it as a pattern that I 
> would necessarily recommend over the current fragment encoding.
> 
> If we mover to post message it would include API  for logout and session 
> management, not just login.
> 
> John B.
> 
> 
>> On Jul 1, 2016, at 6:43 PM, Liyu Yi > <mailto:liy...@gmail.com>> wrote:
>> 
>> Understood there is an Authorization Code grant type; here I am more 
>> focusing on the Implicit grant type. 
>>   
>> also when I mentioned POST, I did not mean postMessage, it is simply the 
>> HTTP POST. Specifically it is more like this ...
>> 
>> 
>> 
>> 4.2 <https://tools.ietf.org/html/rfc6749#section-4.2>. Implicit Grant 
>> (modified)
>>  +--+
>>  | Resource |
>>  |  Owner   |
>>  |  |
>>  +--+
>>   ^
>>   |
>>  (B)
>>  +|-+  Client Identifier +---+
>>  | -+(A)-- & Redirection URI --->|   |
>>  |  User-   || Authorization |
>>  |  Agent  -|(B)-- User authenticates -->| Server|
>>  |  ||   |
>>  |  |<---(C)- Response embedded JS -<|   |
>>  |  |  with Access Token +---+
>>  |  |in JS content, which will be posted to Resource 
>> Server
>>  |  |+---+
>>  |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
>>  |  | with Access Token  | Client|
>>  |  ||Resource   |
>>  | (F)  |<---(E)- RS Script <|   |
>>  |  | with Access Token  +---+
>>  +-|+
>>||
>>   (A)  (G) Access Token
>>||
>>^v
>>  +-+
>>  | |
>>  |  Client |
>>  | |
>>  +-+
>> 
>> 
>> 
>>Figure 4: Implicit Grant Flow
>> 
>>The flow illustrated in Figure 4 includes the following steps:
>> 
>>(A)  The client initiates the flow by directing the resource owner's
>> user-agent to the authorization endpoint.  The client includes
>> its client identifier, requested scope, local state, and a
>> redirection URI to which the authorization server will send the
>> user-agent back once access is granted (or denied).
>> 
>>(B)  The authorization server authenticates the resource owner (via
>> the user-agent) and establishes whether the resource owner
>> grants or denies the client's access request.
>> 
>>(C)  Assuming the resource owner grants access, the authorization
>> server responds with a JavaScript logic which automatically posts to 
>> "redirection" URI provided earlier.  The JavaScript includes
>> the access token in the URI fragment.
>> 
>>(D)  The user-agent does the post with the access token. Granted,  
>>   user agent can actually do post without the access token  
>> in a different iframe, 
>>   then use postMessage to pass the 

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

I think, the intention was not to share AT with the web-hosted client resource. 
As you can see in the original flow the latter never receives the AT, it simply 
provides code that can get AT from a fragment and some UI. In the modified flow 
AT is sent to the web-hosted client resource, which makes security worse in my 
view, because you have your AT exposed in two places now - in the User Agent 
*and* in the web-hosted client resource.


 
  From: John Bradley 
 To: Liyu Yi  
Cc: Oleg Gryb ; "" 
 Sent: Friday, July 1, 2016 4:06 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
I take it that Web-hosted client resource is part of the client.
I think perhaps you have client and resource serve r mixed up a bit in your 
diagram.
Yes you could do that but it is not a great way to build the client as it will 
blow away context.  You can do it but people generally want to start the 
application in the browser first and then call out to the IdP  in a iFrame.
What you propose would work more or less.  I don’t see it as a pattern that I 
would necessarily recommend over the current fragment encoding.
If we mover to post message it would include API  for logout and session 
management, not just login.
John B.


On Jul 1, 2016, at 6:43 PM, Liyu Yi  wrote:
Understood there is an Authorization Code grant type; here I am more focusing 
on the Implicit grant type.   also when I mentioned POST, I did not mean 
postMessage, it is simply the HTTP POST. Specifically it is more like this ...



4.2. Implicit Grant (modified)
 +--+
 | Resource |
 |  Owner   |
 |  |
 +--+
  ^
  |
 (B)
 +|-+  Client Identifier +---+
 | -+(A)-- & Redirection URI --->|   |
 |  User-   || Authorization |
 |  Agent  -|(B)-- User authenticates -->| Server|
 |  ||   |
 |  |<---(C)- Response embedded JS -<|   |
 |  |  with Access Token +---+
 |  |in JS content, which will be posted to Resource 
Server
 |  |+---+
 |  |(D)-- JS post to RS URI --->|   Web-Hosted  |
 |  | with Access Token  | Client|
 |  ||Resource   |
 | (F)  |<---(E)- RS Script <|   |
 |  | with Access Token  +---+
 +-|+
   ||
  (A)  (G) Access Token
   ||
   ^v
 +-+
 | |
 |  Client |
 | |
 +-+



   Figure 4: Implicit Grant Flow

   The flow illustrated in Figure 4 includes the following steps:

   (A)  The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint.  The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

   (B)  The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
server responds with a JavaScript logic which automatically posts to 
"redirection" URI provided earlier.  The JavaScript includes
the access token in the URI fragment.

   (D)  The user-agent does the post with the access token. Granted,
user agent can actually do post without the access token  in a 
different iframe,   then use postMessage to pass the token 
over, but I do not see why get it need that compexity.

On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel  wrote:

Thanks John! Yes, we're following the CORS based flow you've described below 
(though I should note that the actual redirection back to the client could be a 
302, or could be a simple Web link that the user follows from an authorization 
page; this is up to the authorization server). Overall I don't argue that this 
flow is "more secure" than the implicit flow -- though I believe it does help 
client developers avoid some common pitfalls. (For example, clients that, 
through careless programming or poor understanding of the spec, fail to 
validate incoming "state" are still not susceptible to arbitrary token 
injection, which means at least they won't readily be tricked into using a 
token designated for an entirely different client. With poorly written implicit 
flow clients, this is an issue.) That sa

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

'm hoping you can clarify why you say that 
>>>> "HTTP POST... won't work well for... [a] single page OAuth client"?
>>>> 
>>>> We commonly build single-page apps that act as OAuth clients for SMART 
>>>> (e.g. this sample app 
>>>> <https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
>>>>  ), and we've had good experience with the technique. Could you elaborate?
>>>> 
>>>>   -J
>>>> 
>>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley >>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>> HEART only supports web server clients at the moment.   That might change 
>>>> in future to support native apps if that an be made to support the 
>>>> security requirements of Heath IT.
>>>> 
>>>> So the thing HTTP POST responses won’t work well for is a type of in 
>>>> browser single page OAuth client.  That still needs fragment encoded 
>>>> responses or the new post-message Java Script API approach.
>>>> 
>>>> John B.
>>>> 
>>>> 
>>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel >>>> <mailto:jman...@gmail.com>> wrote:
>>>>> 
>>>>> Thanks Justin,
>>>>> 
>>>>> To clarify: John's comment and my question were about POST. (I do 
>>>>> understand the behavior of HTTP POST and of window.postMessage; these are 
>>>>> totally different things.) From my perspective in SMART Health IT, we use 
>>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>>>> authorization spec <http://docs.smarthealthit.org/authorization/> even 
>>>>> for public clients, and it has worked very well for us, with about a 
>>>>> dozen electronic health record servers supporting this approach. That's 
>>>>> why I was curious to hear John's perspective about limitations.
>>>>> 
>>>>>   -J
>>>>> 
>>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb >>>> <mailto:oleg_g...@yahoo.com>> wrote:
>>>>> > POST will send things to the server, which isn’t desirable if your 
>>>>> > client is solely in the browser
>>>>> Why it's not desirable, assuming that we disregard performance? You can 
>>>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
>>>>> this?
>>>>> 
>>>>> 
>>>>> From: Justin Richer mailto:jric...@mit.edu>>
>>>>> To: Josh Mandel mailto:jman...@gmail.com>> 
>>>>> Cc: Oleg Gryb mailto:o...@gryb.info>>; ">>>> <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu 
>>>>> Yi mailto:liy...@gmail.com>>
>>>>> Sent: Friday, July 1, 2016 2:00 PM
>>>>> 
>>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit 
>>>>> grant
>>>>> 
>>>>> POST will send things to the server, which isn’t desirable if your client 
>>>>> is solely in the browser. postMessage is a browser API and not to be 
>>>>> confused with HTTP POST. postMessage messages stay (or can stay) within 
>>>>> the browser, which is the intent here.
>>>>> 
>>>>>  — Justin
>>>>> 
>>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel >>>>> <mailto:jman...@gmail.com>> wrote:
>>>>>> 
>>>>> 
>>>>> John,
>>>>> 
>>>>> Could you clarify what you mean by "POST doesn't really work"? Do you 
>>>>> just mean that CORS support (e.g., http://caniuse.com/#feat=cors 
>>>>> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
>>>>> 
>>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >>>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>>> Yes but POST doesn't really work for in browser apps.
>>>>> 
>>>>> If it is a server app it should be using the code flow with GET or POST 
>>>>> as you like.
>>>>> 
>>>>> If we do a  post message based binding it will be targeted at in browser 
>>>>> applications.
>>>>> 
>>>>> John B.
>>>>> 
>>>>> On Fri, Jul

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

ST. (I do 
>>>> understand the behavior of HTTP POST and of window.postMessage; these are 
>>>> totally different things.) From my perspective in SMART Health IT, we use 
>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>>> authorization spec <http://docs.smarthealthit.org/authorization/> even for 
>>>> public clients, and it has worked very well for us, with about a dozen 
>>>> electronic health record servers supporting this approach. That's why I 
>>>> was curious to hear John's perspective about limitations.
>>>> 
>>>>   -J
>>>> 
>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb >>> <mailto:oleg_g...@yahoo.com>> wrote:
>>>> > POST will send things to the server, which isn’t desirable if your 
>>>> > client is solely in the browser
>>>> Why it's not desirable, assuming that we disregard performance? You can 
>>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
>>>> this?
>>>> 
>>>> 
>>>> From: Justin Richer mailto:jric...@mit.edu>>
>>>> To: Josh Mandel mailto:jman...@gmail.com>> 
>>>> Cc: Oleg Gryb mailto:o...@gryb.info>>; ">>> <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu 
>>>> Yi mailto:liy...@gmail.com>>
>>>> Sent: Friday, July 1, 2016 2:00 PM
>>>> 
>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>>>> 
>>>> POST will send things to the server, which isn’t desirable if your client 
>>>> is solely in the browser. postMessage is a browser API and not to be 
>>>> confused with HTTP POST. postMessage messages stay (or can stay) within 
>>>> the browser, which is the intent here.
>>>> 
>>>>  — Justin
>>>> 
>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel >>>> <mailto:jman...@gmail.com>> wrote:
>>>>> 
>>>> 
>>>> John,
>>>> 
>>>> Could you clarify what you mean by "POST doesn't really work"? Do you just 
>>>> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
>>>> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
>>>> 
>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>> Yes but POST doesn't really work for in browser apps.
>>>> 
>>>> If it is a server app it should be using the code flow with GET or POST as 
>>>> you like.
>>>> 
>>>> If we do a  post message based binding it will be targeted at in browser 
>>>> applications.
>>>> 
>>>> John B.
>>>> 
>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi >>> <mailto:liy...@gmail.com>> wrote:
>>>> BTW, I do not see any significant performance concerns for post. Parsing 
>>>> and executing the Javascript logic for post operation will be on the 
>>>> client side, no extra server load is introduced.
>>>> 
>>>> Plus post will remove the size restriction of the URL length.
>>>> 
>>>> -- Liyu 
>>>> 
>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi >>> <mailto:liy...@gmail.com>> wrote:
>>>> Thanks for the great comments and advices.
>>>> 
>>>> I think it is a good idea for the working group to revise the fragment 
>>>> part in the spec, since there might be public available tools already 
>>>> implemented this approach and people can end up with a solution with 
>>>> serious security loopholes.
>>>> 
>>>> The re-append issue can be mitigate by a logic on Resource Server which 
>>>> carefully re-writes/removes the fragment in any redirect, if the the 
>>>> redirect can not be avoided.
>>>> 
>>>> -- Liyu
>>>>  
>>>> 
>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley >>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>> This behaviour started changing around 2011
>>>> 
>>>> From HTTP/1.1
>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
>>>> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>>>>   f the Location value provided in a 3xx (Redirection) response does
>>>>not have

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

t;>> 
>>> I appreciate your response. I'm hoping you can clarify why you say that 
>>> "HTTP POST... won't work well for... [a] single page OAuth client"?
>>> 
>>> We commonly build single-page apps that act as OAuth clients for SMART 
>>> (e.g. this sample app 
>>> <https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
>>>  ), and we've had good experience with the technique. Could you elaborate?
>>> 
>>>   -J
>>> 
>>> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley >> <mailto:ve7...@ve7jtb.com>> wrote:
>>> HEART only supports web server clients at the moment.   That might change 
>>> in future to support native apps if that an be made to support the security 
>>> requirements of Heath IT.
>>> 
>>> So the thing HTTP POST responses won’t work well for is a type of in 
>>> browser single page OAuth client.  That still needs fragment encoded 
>>> responses or the new post-message Java Script API approach.
>>> 
>>> John B.
>>> 
>>> 
>>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel >>> <mailto:jman...@gmail.com>> wrote:
>>>> 
>>>> Thanks Justin,
>>>> 
>>>> To clarify: John's comment and my question were about POST. (I do 
>>>> understand the behavior of HTTP POST and of window.postMessage; these are 
>>>> totally different things.) From my perspective in SMART Health IT, we use 
>>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>>> authorization spec <http://docs.smarthealthit.org/authorization/> even for 
>>>> public clients, and it has worked very well for us, with about a dozen 
>>>> electronic health record servers supporting this approach. That's why I 
>>>> was curious to hear John's perspective about limitations.
>>>> 
>>>>   -J
>>>> 
>>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb >>> <mailto:oleg_g...@yahoo.com>> wrote:
>>>> > POST will send things to the server, which isn’t desirable if your 
>>>> > client is solely in the browser
>>>> Why it's not desirable, assuming that we disregard performance? You can 
>>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
>>>> this?
>>>> 
>>>> 
>>>> From: Justin Richer mailto:jric...@mit.edu>>
>>>> To: Josh Mandel mailto:jman...@gmail.com>> 
>>>> Cc: Oleg Gryb mailto:o...@gryb.info>>; ">>> <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu 
>>>> Yi mailto:liy...@gmail.com>>
>>>> Sent: Friday, July 1, 2016 2:00 PM
>>>> 
>>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>>>> 
>>>> POST will send things to the server, which isn’t desirable if your client 
>>>> is solely in the browser. postMessage is a browser API and not to be 
>>>> confused with HTTP POST. postMessage messages stay (or can stay) within 
>>>> the browser, which is the intent here.
>>>> 
>>>>  — Justin
>>>> 
>>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel >>>> <mailto:jman...@gmail.com>> wrote:
>>>>> 
>>>> 
>>>> John,
>>>> 
>>>> Could you clarify what you mean by "POST doesn't really work"? Do you just 
>>>> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
>>>> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
>>>> 
>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >>> <mailto:ve7...@ve7jtb.com>> wrote:
>>>> Yes but POST doesn't really work for in browser apps.
>>>> 
>>>> If it is a server app it should be using the code flow with GET or POST as 
>>>> you like.
>>>> 
>>>> If we do a  post message based binding it will be targeted at in browser 
>>>> applications.
>>>> 
>>>> John B.
>>>> 
>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi >>> <mailto:liy...@gmail.com>> wrote:
>>>> BTW, I do not see any significant performance concerns for post. Parsing 
>>>> and executing the Javascript logic for post operation will be on the 
>>>> client side, no extra se

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

I'm aware about exploits related to improper redirect_url validation, which was 
FB case, no qs here,  but I still can't understand if appending a fragment to 
Location by a browser makes this exploit simpler or can lead to other exploits 
that have not been described yet.


 
  From: John Bradley 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Friday, July 1, 2016 2:21 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
If the attacker can modify the redirect URI to anything like an embedded add 
that will do a 302 redirect then the recipient of the redirect can load JS to 
extract the access token.
This has happened at Facebook so many times I have lost count.   It is not 
theoretical, it happens all the time.One reason you need to do exact 
redirect_uri matching in the AS but people are not so good at following that 
and take redirects to any URI on the host in some cases.
When used correctly for a real in web client it is fine.  For a web server 
client it introduces unnecessary risks over the code flow, or hybrid flow using 
POST.
Others may differ with my opinion.
John B.

On Jul 1, 2016, at 4:52 PM, Oleg Gryb  wrote:
John,
Thanks, very useful. However, I'm still trying to figure out why it's 
dangerous. Fragment doesn't travel to a server in this new flow either. 
Appending it to Location header is done by the browser who needs to memorize 
what the original request was. If the original request had a fragment and the 
browser got redirected, Location header will be appended by the browser.
Are you saying that this is dangerous because the browser would *always* need 
to store the fragment somewhere in its memory just in case if a server decides 
to redirect?
So an attack vector here is that an imposter can try to retrieve the fragment 
from the browser's memory somehow. Is my understanding correct?
Oleg.


 
  From: John Bradley 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Friday, July 1, 2016 11:33 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
This behaviour started changing around 2011
>From HTTP/1.1See https://tools.ietf.org/html/rfc7231#section-7.1.2I      f the 
>Location value provided in a 3xx (Redirection) response does   not have a 
>fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"; might result in a 303 (See Other)
   response containing the header field:

 Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim”
   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"; might result in a 301
   (Moved Permanently) response containing the header field:

 Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry";, preserving the original
   fragment identifier.


This blog also explores the 
change.https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was  when 
originally specified" - thanks Jim. Looks like a good reason for vetting this 
flow out.
John,Please provide more details/links about re-appending fragments. 
Thanks,Oleg.

 
  From: Jim Manico 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Thursday, June 30, 2016 10:25 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
Oleg! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).
He also mentioned details about fragment leakage:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,--Jim Manico@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:


We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with POST would mean a significant performance

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Josh Mandel]

ing HTTP POST responses won’t work well for is a type of in
>>> browser single page OAuth client.  That still needs fragment encoded
>>> responses or the new post-message Java Script API approach.
>>>
>>> John B.
>>>
>>>
>>> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
>>>
>>> Thanks Justin,
>>>
>>> To clarify: John's comment and my question were about POST. (I do
>>> understand the behavior of HTTP POST and of window.postMessage; these are
>>> totally different things.) From my perspective in SMART Health IT, we use
>>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>>> authorization
>>> spec <http://docs.smarthealthit.org/authorization/> even for public
>>> clients, and it has worked very well for us, with about a dozen electronic
>>> health record servers supporting this approach. That's why I was curious to
>>> hear John's perspective about limitations.
>>>
>>>   -J
>>>
>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:
>>>
>>>> > POST will send things to the server, which isn’t desirable if your
>>>> client is solely in the browser
>>>> Why it's not desirable, assuming that we disregard performance? You can
>>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with
>>>> this?
>>>>
>>>>
>>>> --
>>>> *From:* Justin Richer 
>>>> *To:* Josh Mandel 
>>>> *Cc:* Oleg Gryb ; "" ;
>>>> Liyu Yi 
>>>> *Sent:* Friday, July 1, 2016 2:00 PM
>>>>
>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as
>>>> Implicit grant
>>>>
>>>> POST will send things to the server, which isn’t desirable if your
>>>> client is solely in the browser. postMessage is a browser API and not to be
>>>> confused with HTTP POST. postMessage messages stay (or can stay) within the
>>>> browser, which is the intent here.
>>>>
>>>>  — Justin
>>>>
>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:
>>>>
>>>> John,
>>>>
>>>> Could you clarify what you mean by "POST doesn't really work"? Do you
>>>> just mean that CORS support (e.g., http://caniuse.com/#feat=cors)
>>>> isn't universal, or something more?
>>>>
>>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  wrote:
>>>>
>>>> Yes but POST doesn't really work for in browser apps.
>>>>
>>>> If it is a server app it should be using the code flow with GET or POST
>>>> as you like.
>>>>
>>>> If we do a  post message based binding it will be targeted at in
>>>> browser applications.
>>>>
>>>> John B.
>>>>
>>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:
>>>>
>>>> BTW, I do not see any significant performance concerns for post.
>>>> Parsing and executing the Javascript logic for post operation will be on
>>>> the client side, no extra server load is introduced.
>>>>
>>>> Plus post will remove the size restriction of the URL length.
>>>>
>>>> -- Liyu
>>>>
>>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>>>>
>>>> Thanks for the great comments and advices.
>>>>
>>>> I think it is a good idea for the working group to revise the fragment
>>>> part in the spec, since there might be public available tools already
>>>> implemented this approach and people can end up with a solution with
>>>> serious security loopholes.
>>>>
>>>> The re-append issue can be mitigate by a logic on Resource Server which
>>>> carefully re-writes/removes the fragment in any redirect, if the the
>>>> redirect can not be avoided.
>>>>
>>>> -- Liyu
>>>>
>>>>
>>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley 
>>>> wrote:
>>>>
>>>> This behaviour started changing around 2011
>>>>
>>>> From HTTP/1.1
>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>>>>   f the Location value provided in a 3xx (Redirection) response does
>>>>
>>>>not have a fragment component, a user agent MUST process the
>>>>    r

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Jim Manico]

HTTP POST requests are also a lot more difficult to cache server side compared 
to URI's which are easier to cache. I'm likely not explaining this well, but I 
believe it's a webscale concern.

--
Jim Manico
@Manicode

> On Jul 1, 2016, at 11:01 PM, Oleg Gryb  wrote:
> 
> AFAIR, they were talking about cost of this additional POST on the server 
> side, which was not good for high volume traffic (millions requests per day). 
> I'll try to dig it out to find more details. 
> 
> 
> From: Liyu Yi 
> To: John Bradley  
> Cc: Oleg Gryb ; Jim Manico ; 
> "oauth@ietf.org" 
> Sent: Friday, July 1, 2016 1:42 PM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> BTW, I do not see any significant performance concerns for post. Parsing and 
> executing the Javascript logic for post operation will be on the client side, 
> no extra server load is introduced.
> 
> Plus post will remove the size restriction of the URL length.
> 
> -- Liyu 
> 
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
> Thanks for the great comments and advices.
> 
> I think it is a good idea for the working group to revise the fragment part 
> in the spec, since there might be public available tools already implemented 
> this approach and people can end up with a solution with serious security 
> loopholes.
> 
> The re-append issue can be mitigate by a logic on Resource Server which 
> carefully re-writes/removes the fragment in any redirect, if the the redirect 
> can not be avoided.
> 
> -- Liyu
>  
> 
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim"; might result in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
> 
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim”
> 
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry"; might result in a 301
>(Moved Permanently) response containing the header field:
> 
>  Location: http://www.example.net/index.html
> 
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry";, preserving the original
>fragment identifier.
> 
> 
> This blog also explores the change.
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
> 
> 
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was  when 
>> originally specified" - thanks Jim. Looks like a good reason for vetting 
>> this flow out.
>> 
>> John,
>> Please provide more details/links about re-appending fragments. 
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico 
>> To: Oleg Gryb  
>> Cc: "oauth@ietf.org" ; Liyu Yi 
>> Sent: Thursday, June 30, 2016 10:25 PM
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> Oleg! Hello! Great to see you pop up here with a similar concern.
>> 
>> John Bradley just answered this thread with the details I was looking for 
>> (thanks John, hat tip your way).
>> 
>> He also mentioned details about fragment leakage:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was when 
>> originally specified"
>> 
>> Again, I'm new here but I'm grateful for this conversation.
>> 
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>> 
>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:
>>> 
>>> We've discussed access tokens in URI back in 2010 
>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There 
>>> were two major objectives when I was saying that it's not secure:
>>> 
>>> 1. Fragment is not sent to

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

;> 
>>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb >> <mailto:oleg_g...@yahoo.com>> wrote:
>>> > POST will send things to the server, which isn’t desirable if your client 
>>> > is solely in the browser
>>> Why it's not desirable, assuming that we disregard performance? You can 
>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
>>> this?
>>> 
>>> 
>>> From: Justin Richer mailto:jric...@mit.edu>>
>>> To: Josh Mandel mailto:jman...@gmail.com>> 
>>> Cc: Oleg Gryb mailto:o...@gryb.info>>; ">> <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu Yi 
>>> mailto:liy...@gmail.com>>
>>> Sent: Friday, July 1, 2016 2:00 PM
>>> 
>>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>>> 
>>> POST will send things to the server, which isn’t desirable if your client 
>>> is solely in the browser. postMessage is a browser API and not to be 
>>> confused with HTTP POST. postMessage messages stay (or can stay) within the 
>>> browser, which is the intent here.
>>> 
>>>  — Justin
>>> 
>>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel >>> <mailto:jman...@gmail.com>> wrote:
>>>> 
>>> 
>>> John,
>>> 
>>> Could you clarify what you mean by "POST doesn't really work"? Do you just 
>>> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
>>> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
>>> 
>>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley >> <mailto:ve7...@ve7jtb.com>> wrote:
>>> Yes but POST doesn't really work for in browser apps.
>>> 
>>> If it is a server app it should be using the code flow with GET or POST as 
>>> you like.
>>> 
>>> If we do a  post message based binding it will be targeted at in browser 
>>> applications.
>>> 
>>> John B.
>>> 
>>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi >> <mailto:liy...@gmail.com>> wrote:
>>> BTW, I do not see any significant performance concerns for post. Parsing 
>>> and executing the Javascript logic for post operation will be on the client 
>>> side, no extra server load is introduced.
>>> 
>>> Plus post will remove the size restriction of the URL length.
>>> 
>>> -- Liyu 
>>> 
>>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi >> <mailto:liy...@gmail.com>> wrote:
>>> Thanks for the great comments and advices.
>>> 
>>> I think it is a good idea for the working group to revise the fragment part 
>>> in the spec, since there might be public available tools already 
>>> implemented this approach and people can end up with a solution with 
>>> serious security loopholes.
>>> 
>>> The re-append issue can be mitigate by a logic on Resource Server which 
>>> carefully re-writes/removes the fragment in any redirect, if the the 
>>> redirect can not be avoided.
>>> 
>>> -- Liyu
>>>  
>>> 
>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley >> <mailto:ve7...@ve7jtb.com>> wrote:
>>> This behaviour started changing around 2011
>>> 
>>> From HTTP/1.1
>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
>>> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>>>   f the Location value provided in a 3xx (Redirection) response does
>>>not have a fragment component, a user agent MUST process the
>>>redirection as if the value inherits the fragment component of the
>>>URI reference used to generate the request target (i.e., the
>>>redirection inherits the original reference's fragment, if any).
>>> 
>>>For example, a GET request generated for the URI reference
>>>"http://www.example.org/~tim <http://www.example.org/~tim>" might result 
>>> in a 303 (See Other)
>>>response containing the header field:
>>> 
>>>  Location: /People.html#tim
>>> 
>>>which suggests that the user agent redirect to
>>>"http://www.example.org/People.html#tim 
>>> <http://www.example.org/People.html#tim>”
>>> 
>>>Likewise, a GET request generated for the URI reference
>>>"http://www.example.org/index.html#larry 
>>> <http://www.examp

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Josh Mandel]

I think the confusion here is that I'm not using HEART's OAuth profiles :-)

I'm using the SMART profiles, where we do specify the use of an
authorization code grant even for browser-based public clients (in which
case, no client_secret is issued or used). I'm just trying to understand
your perspective eon why this "won't work well". Perhaps you didn't mean
this comment to refer to browser-based OAuth clients generally?

  -Josh

On Fri, Jul 1, 2016 at 5:45 PM, John Bradley  wrote:

> I don’t think the post response mode is supported by heart so I suspect
> that we are talking about different things.
>
> You are probably using the supported code flow that uses a 302 get to
> return the code to the OAuth client on the server.
> The Web server is then acting as a confidential client to exchange the
> code via a POST (different POST) with the AS token_endpoint.
>
> The Token endpoint will return a access token (AT) and optional refresh
> token (RT).
>
> The web page may be getting the server to make the OAuth calls on it’s
> behalf to the Resource Server, or possibly you are passing the AT from the
> server back to a Java script app that is using CORES to make calls directly
> to the RS without going through the Web server.
>
> Passing the AT back to the user agent from the client is not recommended.
>
> For in browser clients where the JS is using the AT to make the calls
> directly to the RS via CORES the recommended approach is to use the
> fragment encoded response via a 302 to deliver the AT directly to the
> client (It never hits the backend Web server).
>
> However I believe In browser OAuth clients are not currently supported in
> HEART, so I am not quite sure what you are doing.
>
> Perhaps Justin has a better answer.
>
> John B.
>
>
> On Jul 1, 2016, at 5:33 PM, Josh Mandel  wrote:
>
> John,
>
> I appreciate your response. I'm hoping you can clarify why you say that
> "HTTP POST... won't work well for... [a] single page OAuth client"?
>
> We commonly build single-page apps that act as OAuth clients for SMART
> (e.g. this sample app
> <https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
>  ),
> and we've had good experience with the technique. Could you elaborate?
>
>   -J
>
> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley  wrote:
>
>> HEART only supports web server clients at the moment.   That might change
>> in future to support native apps if that an be made to support the security
>> requirements of Heath IT.
>>
>> So the thing HTTP POST responses won’t work well for is a type of in
>> browser single page OAuth client.  That still needs fragment encoded
>> responses or the new post-message Java Script API approach.
>>
>> John B.
>>
>>
>> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
>>
>> Thanks Justin,
>>
>> To clarify: John's comment and my question were about POST. (I do
>> understand the behavior of HTTP POST and of window.postMessage; these are
>> totally different things.) From my perspective in SMART Health IT, we use
>> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
>> authorization
>> spec <http://docs.smarthealthit.org/authorization/> even for public
>> clients, and it has worked very well for us, with about a dozen electronic
>> health record servers supporting this approach. That's why I was curious to
>> hear John's perspective about limitations.
>>
>>   -J
>>
>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:
>>
>>> > POST will send things to the server, which isn’t desirable if your
>>> client is solely in the browser
>>> Why it's not desirable, assuming that we disregard performance? You can
>>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with
>>> this?
>>>
>>>
>>> --
>>> *From:* Justin Richer 
>>> *To:* Josh Mandel 
>>> *Cc:* Oleg Gryb ; "" ;
>>> Liyu Yi 
>>> *Sent:* Friday, July 1, 2016 2:00 PM
>>>
>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
>>> grant
>>>
>>> POST will send things to the server, which isn’t desirable if your
>>> client is solely in the browser. postMessage is a browser API and not to be
>>> confused with HTTP POST. postMessage messages stay (or can stay) within the
>>> browser, which is the intent here.
>>>
>>>  — Justin
>>>
>>> On Jul 1, 2016, at 4:56 PM, J

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

I don’t think the post response mode is supported by heart so I suspect that we 
are talking about different things.

You are probably using the supported code flow that uses a 302 get to return 
the code to the OAuth client on the server.  
The Web server is then acting as a confidential client to exchange the code via 
a POST (different POST) with the AS token_endpoint.

The Token endpoint will return a access token (AT) and optional refresh token 
(RT).

The web page may be getting the server to make the OAuth calls on it’s behalf 
to the Resource Server, or possibly you are passing the AT from the server back 
to a Java script app that is using CORES to make calls directly to the RS 
without going through the Web server.

Passing the AT back to the user agent from the client is not recommended. 

For in browser clients where the JS is using the AT to make the calls directly 
to the RS via CORES the recommended approach is to use the fragment encoded 
response via a 302 to deliver the AT directly to the client (It never hits the 
backend Web server).

However I believe In browser OAuth clients are not currently supported in 
HEART, so I am not quite sure what you are doing.

Perhaps Justin has a better answer.

John B.


> On Jul 1, 2016, at 5:33 PM, Josh Mandel  wrote:
> 
> John,
> 
> I appreciate your response. I'm hoping you can clarify why you say that "HTTP 
> POST... won't work well for... [a] single page OAuth client"?
> 
> We commonly build single-page apps that act as OAuth clients for SMART (e.g. 
> this sample app 
> <https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
>  ), and we've had good experience with the technique. Could you elaborate?
> 
>   -J
> 
> On Fri, Jul 1, 2016 at 5:26 PM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> HEART only supports web server clients at the moment.   That might change in 
> future to support native apps if that an be made to support the security 
> requirements of Heath IT.
> 
> So the thing HTTP POST responses won’t work well for is a type of in browser 
> single page OAuth client.  That still needs fragment encoded responses or the 
> new post-message Java Script API approach.
> 
> John B.
> 
> 
>> On Jul 1, 2016, at 5:16 PM, Josh Mandel > <mailto:jman...@gmail.com>> wrote:
>> 
>> Thanks Justin,
>> 
>> To clarify: John's comment and my question were about POST. (I do understand 
>> the behavior of HTTP POST and of window.postMessage; these are totally 
>> different things.) From my perspective in SMART Health IT, we use the OAuth 
>> 2.0 authorization code flow, including HTTP POST, in our authorization spec 
>> <http://docs.smarthealthit.org/authorization/> even for public clients, and 
>> it has worked very well for us, with about a dozen electronic health record 
>> servers supporting this approach. That's why I was curious to hear John's 
>> perspective about limitations.
>> 
>>   -J
>> 
>> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb > <mailto:oleg_g...@yahoo.com>> wrote:
>> > POST will send things to the server, which isn’t desirable if your client 
>> > is solely in the browser
>> Why it's not desirable, assuming that we disregard performance? You can 
>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
>> this?
>> 
>> 
>> From: Justin Richer mailto:jric...@mit.edu>>
>> To: Josh Mandel mailto:jman...@gmail.com>> 
>> Cc: Oleg Gryb mailto:o...@gryb.info>>; "> <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu Yi 
>> mailto:liy...@gmail.com>>
>> Sent: Friday, July 1, 2016 2:00 PM
>> 
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> POST will send things to the server, which isn’t desirable if your client is 
>> solely in the browser. postMessage is a browser API and not to be confused 
>> with HTTP POST. postMessage messages stay (or can stay) within the browser, 
>> which is the intent here.
>> 
>>  — Justin
>> 
>>> On Jul 1, 2016, at 4:56 PM, Josh Mandel >> <mailto:jman...@gmail.com>> wrote:
>>> 
>> 
>> John,
>> 
>> Could you clarify what you mean by "POST doesn't really work"? Do you just 
>> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
>> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
>> 
>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley > <mailto:ve7...@ve7jtb.com>> wrote:
>> Yes but POST doesn't really wor

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Josh Mandel]

John,

I appreciate your response. I'm hoping you can clarify why you say that
"HTTP POST... won't work well for... [a] single page OAuth client"?

We commonly build single-page apps that act as OAuth clients for SMART
(e.g. this sample app
<https://github.com/smart-on-fhir/sample-apps/tree/9cd49fe5753a70795c73e1fe58297591c23ca591/authorize>
),
and we've had good experience with the technique. Could you elaborate?

  -J

On Fri, Jul 1, 2016 at 5:26 PM, John Bradley  wrote:

> HEART only supports web server clients at the moment.   That might change
> in future to support native apps if that an be made to support the security
> requirements of Heath IT.
>
> So the thing HTTP POST responses won’t work well for is a type of in
> browser single page OAuth client.  That still needs fragment encoded
> responses or the new post-message Java Script API approach.
>
> John B.
>
>
> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
>
> Thanks Justin,
>
> To clarify: John's comment and my question were about POST. (I do
> understand the behavior of HTTP POST and of window.postMessage; these are
> totally different things.) From my perspective in SMART Health IT, we use
> the OAuth 2.0 authorization code flow, including HTTP POST, in our 
> authorization
> spec <http://docs.smarthealthit.org/authorization/> even for public
> clients, and it has worked very well for us, with about a dozen electronic
> health record servers supporting this approach. That's why I was curious to
> hear John's perspective about limitations.
>
>   -J
>
> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:
>
>> > POST will send things to the server, which isn’t desirable if your
>> client is solely in the browser
>> Why it's not desirable, assuming that we disregard performance? You can
>> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with
>> this?
>>
>>
>> ------------------
>> *From:* Justin Richer 
>> *To:* Josh Mandel 
>> *Cc:* Oleg Gryb ; "" ;
>> Liyu Yi 
>> *Sent:* Friday, July 1, 2016 2:00 PM
>>
>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
>> grant
>>
>> POST will send things to the server, which isn’t desirable if your client
>> is solely in the browser. postMessage is a browser API and not to be
>> confused with HTTP POST. postMessage messages stay (or can stay) within the
>> browser, which is the intent here.
>>
>>  — Justin
>>
>> On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:
>>
>> John,
>>
>> Could you clarify what you mean by "POST doesn't really work"? Do you
>> just mean that CORS support (e.g., http://caniuse.com/#feat=cors) isn't
>> universal, or something more?
>>
>> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  wrote:
>>
>> Yes but POST doesn't really work for in browser apps.
>>
>> If it is a server app it should be using the code flow with GET or POST
>> as you like.
>>
>> If we do a  post message based binding it will be targeted at in browser
>> applications.
>>
>> John B.
>>
>> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:
>>
>> BTW, I do not see any significant performance concerns for post. Parsing
>> and executing the Javascript logic for post operation will be on the client
>> side, no extra server load is introduced.
>>
>> Plus post will remove the size restriction of the URL length.
>>
>> -- Liyu
>>
>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>>
>> Thanks for the great comments and advices.
>>
>> I think it is a good idea for the working group to revise the fragment
>> part in the spec, since there might be public available tools already
>> implemented this approach and people can end up with a solution with
>> serious security loopholes.
>>
>> The re-append issue can be mitigate by a logic on Resource Server which
>> carefully re-writes/removes the fragment in any redirect, if the the
>> redirect can not be avoided.
>>
>> -- Liyu
>>
>>
>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
>>
>> This behaviour started changing around 2011
>>
>> From HTTP/1.1
>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>>   f the Location value provided in a 3xx (Redirection) response does
>>
>>not have a fragment component, a user agent MUST process the
>>redirection as if the value inherits the fragment component of the
>>URI reference used to generate the request ta

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

HEART only supports web server clients at the moment.   That might change in 
future to support native apps if that an be made to support the security 
requirements of Heath IT.

So the thing HTTP POST responses won’t work well for is a type of in browser 
single page OAuth client.  That still needs fragment encoded responses or the 
new post-message Java Script API approach.

John B.


> On Jul 1, 2016, at 5:16 PM, Josh Mandel  wrote:
> 
> Thanks Justin,
> 
> To clarify: John's comment and my question were about POST. (I do understand 
> the behavior of HTTP POST and of window.postMessage; these are totally 
> different things.) From my perspective in SMART Health IT, we use the OAuth 
> 2.0 authorization code flow, including HTTP POST, in our authorization spec 
> <http://docs.smarthealthit.org/authorization/> even for public clients, and 
> it has worked very well for us, with about a dozen electronic health record 
> servers supporting this approach. That's why I was curious to hear John's 
> perspective about limitations.
> 
>   -J
> 
> On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  <mailto:oleg_g...@yahoo.com>> wrote:
> > POST will send things to the server, which isn’t desirable if your client 
> > is solely in the browser
> Why it's not desirable, assuming that we disregard performance? You can 
> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with 
> this?
> 
> 
> From: Justin Richer mailto:jric...@mit.edu>>
> To: Josh Mandel mailto:jman...@gmail.com>> 
> Cc: Oleg Gryb mailto:o...@gryb.info>>; " <mailto:oauth@ietf.org>>" mailto:oauth@ietf.org>>; Liyu Yi 
> mailto:liy...@gmail.com>>
> Sent: Friday, July 1, 2016 2:00 PM
> 
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> POST will send things to the server, which isn’t desirable if your client is 
> solely in the browser. postMessage is a browser API and not to be confused 
> with HTTP POST. postMessage messages stay (or can stay) within the browser, 
> which is the intent here.
> 
>  — Justin
> 
>> On Jul 1, 2016, at 4:56 PM, Josh Mandel > <mailto:jman...@gmail.com>> wrote:
>> 
> 
> John,
> 
> Could you clarify what you mean by "POST doesn't really work"? Do you just 
> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
> 
> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> Yes but POST doesn't really work for in browser apps.
> 
> If it is a server app it should be using the code flow with GET or POST as 
> you like.
> 
> If we do a  post message based binding it will be targeted at in browser 
> applications.
> 
> John B.
> 
> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  <mailto:liy...@gmail.com>> wrote:
> BTW, I do not see any significant performance concerns for post. Parsing and 
> executing the Javascript logic for post operation will be on the client side, 
> no extra server load is introduced.
> 
> Plus post will remove the size restriction of the URL length.
> 
> -- Liyu 
> 
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  <mailto:liy...@gmail.com>> wrote:
> Thanks for the great comments and advices.
> 
> I think it is a good idea for the working group to revise the fragment part 
> in the spec, since there might be public available tools already implemented 
> this approach and people can end up with a solution with serious security 
> loopholes.
> 
> The re-append issue can be mitigate by a logic on Resource Server which 
> carefully re-writes/removes the fragment in any redirect, if the the redirect 
> can not be avoided.
> 
> -- Liyu
>  
> 
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim <http://www.example.org/~tim>" might result 
> in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
>

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

If the attacker can modify the redirect URI to anything like an embedded add 
that will do a 302 redirect then the recipient of the redirect can load JS to 
extract the access token.

This has happened at Facebook so many times I have lost count.   It is not 
theoretical, it happens all the time.
One reason you need to do exact redirect_uri matching in the AS but people are 
not so good at following that and take redirects to any URI on the host in some 
cases.

When used correctly for a real in web client it is fine.  For a web server 
client it introduces unnecessary risks over the code flow, or hybrid flow using 
POST.

Others may differ with my opinion.

John B.

> On Jul 1, 2016, at 4:52 PM, Oleg Gryb  wrote:
> 
> John,
> 
> Thanks, very useful. However, I'm still trying to figure out why it's 
> dangerous. Fragment doesn't travel to a server in this new flow either. 
> Appending it to Location header is done by the browser who needs to memorize 
> what the original request was. If the original request had a fragment and the 
> browser got redirected, Location header will be appended by the browser.
> 
> Are you saying that this is dangerous because the browser would *always* need 
> to store the fragment somewhere in its memory just in case if a server 
> decides to redirect?
> 
> So an attack vector here is that an imposter can try to retrieve the fragment 
> from the browser's memory somehow. Is my understanding correct?
> 
> Oleg.
> 
> 
> From: John Bradley 
> To: Oleg Gryb  
> Cc: "oauth@ietf.org" ; Liyu Yi 
> Sent: Friday, July 1, 2016 11:33 AM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim <http://www.example.org/~tim>" might result 
> in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
> 
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim 
> <http://www.example.org/People.html#tim>”
> 
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry 
> <http://www.example.org/index.html#larry>" might result in a 301
>(Moved Permanently) response containing the header field:
> 
>  Location: http://www.example.net/index.html 
> <http://www.example.net/index.html>
> 
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry 
> <http://www.example.net/index.html#larry>", preserving the original
>fragment identifier.
> 
> 
> This blog also explores the change.
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>  
> <https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/>
> 
> 
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > <mailto:oleg_g...@yahoo.com>> wrote:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was  when 
>> originally specified" - thanks Jim. Looks like a good reason for vetting 
>> this flow out.
>> 
>> John,
>> Please provide more details/links about re-appending fragments. 
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico mailto:j...@manicode.com>>
>> To: Oleg Gryb mailto:o...@gryb.info>> 
>> Cc: "oauth@ietf.org <mailto:oauth@ietf.org>" > <mailto:oauth@ietf.org>>; Liyu Yi > <mailto:liy...@gmail.com>>
>> Sent: Thursday, June 30, 2016 10:25 PM
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> Oleg! Hello! Great to see you pop up here with a similar concern.
>> 
>> John Bradley just answered this thread with the details I was looking for 
>> (thanks John, hat tip your way).
>> 
>> He also mentioned details about fragment leakage:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless t

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Josh Mandel]

Thanks Justin,

To clarify: John's comment and my question were about POST. (I do
understand the behavior of HTTP POST and of window.postMessage; these are
totally different things.) From my perspective in SMART Health IT, we use
the OAuth 2.0 authorization code flow, including HTTP POST, in our
authorization
spec <http://docs.smarthealthit.org/authorization/> even for public
clients, and it has worked very well for us, with about a dozen electronic
health record servers supporting this approach. That's why I was curious to
hear John's perspective about limitations.

  -J

On Fri, Jul 1, 2016 at 5:09 PM, Oleg Gryb  wrote:

> > POST will send things to the server, which isn’t desirable if your
> client is solely in the browser
> Why it's not desirable, assuming that we disregard performance? You can
> generate HTTP POST from JS, e.g. through an AJAX call. What is wrong with
> this?
>
>
> --
> *From:* Justin Richer 
> *To:* Josh Mandel 
> *Cc:* Oleg Gryb ; "" ;
> Liyu Yi 
> *Sent:* Friday, July 1, 2016 2:00 PM
>
> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
> grant
>
> POST will send things to the server, which isn’t desirable if your client
> is solely in the browser. postMessage is a browser API and not to be
> confused with HTTP POST. postMessage messages stay (or can stay) within the
> browser, which is the intent here.
>
>  — Justin
>
> On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:
>
> John,
>
> Could you clarify what you mean by "POST doesn't really work"? Do you
> just mean that CORS support (e.g., http://caniuse.com/#feat=cors) isn't
> universal, or something more?
>
> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  wrote:
>
> Yes but POST doesn't really work for in browser apps.
>
> If it is a server app it should be using the code flow with GET or POST as
> you like.
>
> If we do a  post message based binding it will be targeted at in browser
> applications.
>
> John B.
>
> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:
>
> BTW, I do not see any significant performance concerns for post. Parsing
> and executing the Javascript logic for post operation will be on the client
> side, no extra server load is introduced.
>
> Plus post will remove the size restriction of the URL length.
>
> -- Liyu
>
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>
> Thanks for the great comments and advices.
>
> I think it is a good idea for the working group to revise the fragment
> part in the spec, since there might be public available tools already
> implemented this approach and people can end up with a solution with
> serious security loopholes.
>
> The re-append issue can be mitigate by a logic on Resource Server which
> carefully re-writes/removes the fragment in any redirect, if the the
> redirect can not be avoided.
>
> -- Liyu
>
>
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
>
> This behaviour started changing around 2011
>
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>   f the Location value provided in a 3xx (Redirection) response does
>
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
>
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim"; might result in a 303 (See Other)
>response containing the header field:
>
>  Location: /People.html#tim
>
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim”
>
>
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry"; might result in a 301
>(Moved Permanently) response containing the header field:
>
>  Location: http://www.example.net/index.html
>
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry";, preserving the original
>fragment identifier.
>
>
>
> This blog also explores the change.
>
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>
>
> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>
> "Browsers now re-append  fragments across 302 redirects unless they are
> explicitly cleared this makes fragment encoding less safe than it was  when
> originally specified" - thanks Jim. Looks like a good reason for vetting
> this flow out.
>
> John,

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

Justin is correct.

They may have been trying to avoid the client POST to the token endpoint with 
the code.  

That is a separate issue from the question of using a fragment encoded GET 302 
or a JS POST redirect to return from the authorization endpoint.

The response via the browser is smaller and faster if you are using code.

The direct call via the back channel from the client to the server should not 
be a big deal in reality.

If they are larger than Google and have a real performance issue we can talk.

In the mean time for server based clients the recommendation is to use a 
confidential client with code.

John B.
> On Jul 1, 2016, at 5:01 PM, Oleg Gryb  wrote:
> 
> AFAIR, they were talking about cost of this additional POST on the server 
> side, which was not good for high volume traffic (millions requests per day). 
> I'll try to dig it out to find more details. 
> 
> 
> From: Liyu Yi 
> To: John Bradley  
> Cc: Oleg Gryb ; Jim Manico ; 
> "oauth@ietf.org" 
> Sent: Friday, July 1, 2016 1:42 PM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> BTW, I do not see any significant performance concerns for post. Parsing and 
> executing the Javascript logic for post operation will be on the client side, 
> no extra server load is introduced.
> 
> Plus post will remove the size restriction of the URL length.
> 
> -- Liyu 
> 
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  <mailto:liy...@gmail.com>> wrote:
> Thanks for the great comments and advices.
> 
> I think it is a good idea for the working group to revise the fragment part 
> in the spec, since there might be public available tools already implemented 
> this approach and people can end up with a solution with serious security 
> loopholes.
> 
> The re-append issue can be mitigate by a logic on Resource Server which 
> carefully re-writes/removes the fragment in any redirect, if the the redirect 
> can not be avoided.
> 
> -- Liyu
>  
> 
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim <http://www.example.org/~tim>" might result 
> in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
> 
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim 
> <http://www.example.org/People.html#tim>”
> 
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry 
> <http://www.example.org/index.html#larry>" might result in a 301
>(Moved Permanently) response containing the header field:
> 
>  Location: http://www.example.net/index.html 
> <http://www.example.net/index.html>
> 
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry 
> <http://www.example.net/index.html#larry>", preserving the original
>fragment identifier.
> 
> 
> This blog also explores the change.
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>  
> <https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/>
> 
> 
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > <mailto:oleg_g...@yahoo.com>> wrote:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was  when 
>> originally specified" - thanks Jim. Looks like a good reason for vetting 
>> this flow out.
>> 
>> John,
>> Please provide more details/links about re-appending fragments. 
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico mailto:j...@manicode.com>>
>> To: Oleg Gryb mailto:o...@gryb.info>> 
>> Cc: "oauth@ietf.org <mailto:oauth@ietf.org>" > <mailto:oauth@ietf.org>>; Liyu Yi > <mailto:liy...@gmail.com>>
>> Sent: Thursday, June 30, 2016 10:25 PM
>> Subject: Re: [OAUTH-WG] Securi

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

> POST will send things to the server, which isn’t desirable if your client is 
> solely in the browserWhy it's not desirable, assuming that we disregard 
> performance? You can generate HTTP POST from JS, e.g. through an AJAX call. 
> What is wrong with this?


 
  From: Justin Richer 
 To: Josh Mandel  
Cc: Oleg Gryb ; "" ; Liyu Yi 

 Sent: Friday, July 1, 2016 2:00 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
POST will send things to the server, which isn’t desirable if your client is 
solely in the browser. postMessage is a browser API and not to be confused with 
HTTP POST. postMessage messages stay (or can stay) within the browser, which is 
the intent here.
 — Justin

On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:

John,
Could you clarify what you mean by "POST doesn't really work"? Do you just mean 
that CORS support (e.g., http://caniuse.com/#feat=cors) isn't universal, or 
something more?
On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  wrote:

Yes but POST doesn't really work for in browser apps.
If it is a server app it should be using the code flow with GET or POST as you 
like.
If we do a  post message based binding it will be targeted at in browser 
applications.
John B.
On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:

BTW, I do not see any significant performance concerns for post. Parsing and 
executing the Javascript logic for post operation will be on the client side, 
no extra server load is introduced.
Plus post will remove the size restriction of the URL length.
-- Liyu 
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:

Thanks for the great comments and advices.
I think it is a good idea for the working group to revise the fragment part in 
the spec, since there might be public available tools already implemented this 
approach and people can end up with a solution with serious security loopholes.
The re-append issue can be mitigate by a logic on Resource Server which 
carefully re-writes/removes the fragment in any redirect, if the the redirect 
can not be avoided.
-- Liyu 
On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:

This behaviour started changing around 2011
>From HTTP/1.1See https://tools.ietf.org/html/rfc7231#section-7.1.2I      f the 
>Location value provided in a 3xx (Redirection) response does   not have a 
>fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"; might result in a 303 (See Other)
   response containing the header field:

 Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim”
   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"; might result in a 301
   (Moved Permanently) response containing the header field:

 Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry";, preserving the original
   fragment identifier.


This blog also explores the 
change.https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was  when 
originally specified" - thanks Jim. Looks like a good reason for vetting this 
flow out.
John,Please provide more details/links about re-appending fragments. 
Thanks,Oleg.

 
  From: Jim Manico 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Thursday, June 30, 2016 10:25 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
Oleg! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).
He also mentioned details about fragment leakage:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,--Jim Manico@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:


We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with P

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

AFAIR, they were talking about cost of this additional POST on the server side, 
which was not good for high volume traffic (millions requests per day). I'll 
try to dig it out to find more details. 


 
  From: Liyu Yi 
 To: John Bradley  
Cc: Oleg Gryb ; Jim Manico ; 
"oauth@ietf.org" 
 Sent: Friday, July 1, 2016 1:42 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
BTW, I do not see any significant performance concerns for post. Parsing and 
executing the Javascript logic for post operation will be on the client side, 
no extra server load is introduced.
Plus post will remove the size restriction of the URL length.
-- Liyu 
On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:

Thanks for the great comments and advices.
I think it is a good idea for the working group to revise the fragment part in 
the spec, since there might be public available tools already implemented this 
approach and people can end up with a solution with serious security loopholes.
The re-append issue can be mitigate by a logic on Resource Server which 
carefully re-writes/removes the fragment in any redirect, if the the redirect 
can not be avoided.
-- Liyu 
On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:

This behaviour started changing around 2011
>From HTTP/1.1See https://tools.ietf.org/html/rfc7231#section-7.1.2I      f the 
>Location value provided in a 3xx (Redirection) response does   not have a 
>fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"; might result in a 303 (See Other)
   response containing the header field:

 Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim”
   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"; might result in a 301
   (Moved Permanently) response containing the header field:

 Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry";, preserving the original
   fragment identifier.


This blog also explores the 
change.https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was  when 
originally specified" - thanks Jim. Looks like a good reason for vetting this 
flow out.
John,Please provide more details/links about re-appending fragments. 
Thanks,Oleg.

 
  From: Jim Manico 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Thursday, June 30, 2016 10:25 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
Oleg! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).
He also mentioned details about fragment leakage:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,--Jim Manico@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:


We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with POST would mean a significant performance impact in some high volume 
implementations (I think it was Goole folks who were saying this, but I don't 
remember now).
AFAIR, nobody was arguing about browsing history, so it's valid.
So, 6 years later we're at square one with this and I hope that this time the 
community will be more successful with getting rid of secrets in URL.
BTW, Jim, if you can come up with other scenarios when fragments can leak, 
please share. It'll probably help the community with solving this problem 
faster than in 6 years.
Thanks,Oleg.

 
      From: Jim Manico 
 To: Liyu Yi ; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
 > Shouldn’t it be more secure if we change to use a post method for access 
 > token, similar to the SAML does? I say yes. But please note I'm very 

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Justin Richer]

POST will send things to the server, which isn’t desirable if your client is 
solely in the browser. postMessage is a browser API and not to be confused with 
HTTP POST. postMessage messages stay (or can stay) within the browser, which is 
the intent here.

 — Justin

> On Jul 1, 2016, at 4:56 PM, Josh Mandel  wrote:
> 
> John,
> 
> Could you clarify what you mean by "POST doesn't really work"? Do you just 
> mean that CORS support (e.g., http://caniuse.com/#feat=cors 
> <http://caniuse.com/#feat=cors>) isn't universal, or something more?
> 
> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> Yes but POST doesn't really work for in browser apps.
> 
> If it is a server app it should be using the code flow with GET or POST as 
> you like.
> 
> If we do a  post message based binding it will be targeted at in browser 
> applications.
> 
> John B.
> 
> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  <mailto:liy...@gmail.com>> wrote:
> BTW, I do not see any significant performance concerns for post. Parsing and 
> executing the Javascript logic for post operation will be on the client side, 
> no extra server load is introduced.
> 
> Plus post will remove the size restriction of the URL length.
> 
> -- Liyu 
> 
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  <mailto:liy...@gmail.com>> wrote:
> Thanks for the great comments and advices.
> 
> I think it is a good idea for the working group to revise the fragment part 
> in the spec, since there might be public available tools already implemented 
> this approach and people can end up with a solution with serious security 
> loopholes.
> 
> The re-append issue can be mitigate by a logic on Resource Server which 
> carefully re-writes/removes the fragment in any redirect, if the the redirect 
> can not be avoided.
> 
> -- Liyu
>  
> 
> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  <mailto:ve7...@ve7jtb.com>> wrote:
> This behaviour started changing around 2011
> 
> From HTTP/1.1
> See https://tools.ietf.org/html/rfc7231#section-7.1.2 
> <https://tools.ietf.org/html/rfc7231#section-7.1.2>I
>   f the Location value provided in a 3xx (Redirection) response does
>not have a fragment component, a user agent MUST process the
>redirection as if the value inherits the fragment component of the
>URI reference used to generate the request target (i.e., the
>redirection inherits the original reference's fragment, if any).
> 
>For example, a GET request generated for the URI reference
>"http://www.example.org/~tim <http://www.example.org/~tim>" might result 
> in a 303 (See Other)
>response containing the header field:
> 
>  Location: /People.html#tim
> 
>which suggests that the user agent redirect to
>"http://www.example.org/People.html#tim 
> <http://www.example.org/People.html#tim>”
> 
>Likewise, a GET request generated for the URI reference
>"http://www.example.org/index.html#larry 
> <http://www.example.org/index.html#larry>" might result in a 301
>(Moved Permanently) response containing the header field:
> 
>  Location: http://www.example.net/index.html 
> <http://www.example.net/index.html>
> 
>which suggests that the user agent redirect to
>"http://www.example.net/index.html#larry 
> <http://www.example.net/index.html#larry>", preserving the original
>fragment identifier.
> 
> 
> This blog also explores the change.
> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>  
> <https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/>
> 
> 
>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb > <mailto:oleg_g...@yahoo.com>> wrote:
>> 
>> "Browsers now re-append  fragments across 302 redirects unless they are 
>> explicitly cleared this makes fragment encoding less safe than it was  when 
>> originally specified" - thanks Jim. Looks like a good reason for vetting 
>> this flow out.
>> 
>> John,
>> Please provide more details/links about re-appending fragments. 
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico mailto:j...@manicode.com>>
>> To: Oleg Gryb mailto:o...@gryb.info>> 
>> Cc: "oauth@ietf.org <mailto:oauth@ietf.org>" > <mailto:oauth@ietf.org>>; Liyu Yi > <mailto:liy...@gmail.com>>
>> Sent: Thursday, June 30, 2016 10:25 PM
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> Oleg! Hello! G

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Josh Mandel]

John,

Could you clarify what you mean by "POST doesn't really work"? Do you just
mean that CORS support (e.g., http://caniuse.com/#feat=cors) isn't
universal, or something more?

On Fri, Jul 1, 2016 at 4:51 PM, John Bradley  wrote:

> Yes but POST doesn't really work for in browser apps.
>
> If it is a server app it should be using the code flow with GET or POST as
> you like.
>
> If we do a  post message based binding it will be targeted at in browser
> applications.
>
> John B.
>
> On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:
>
>> BTW, I do not see any significant performance concerns for post. Parsing
>> and executing the Javascript logic for post operation will be on the client
>> side, no extra server load is introduced.
>>
>> Plus post will remove the size restriction of the URL length.
>>
>> -- Liyu
>>
>> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>>
>>> Thanks for the great comments and advices.
>>>
>>> I think it is a good idea for the working group to revise the fragment
>>> part in the spec, since there might be public available tools already
>>> implemented this approach and people can end up with a solution with
>>> serious security loopholes.
>>>
>>> The re-append issue can be mitigate by a logic on Resource Server which
>>> carefully re-writes/removes the fragment in any redirect, if the the
>>> redirect can not be avoided.
>>>
>>> -- Liyu
>>>
>>>
>>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
>>>
>>>> This behaviour started changing around 2011
>>>>
>>>> From HTTP/1.1
>>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>>>>   f the Location value provided in a 3xx (Redirection) response does
>>>>
>>>>not have a fragment component, a user agent MUST process the
>>>>redirection as if the value inherits the fragment component of the
>>>>URI reference used to generate the request target (i.e., the
>>>>redirection inherits the original reference's fragment, if any).
>>>>
>>>>For example, a GET request generated for the URI reference
>>>>"http://www.example.org/~tim"; might result in a 303 (See Other)
>>>>response containing the header field:
>>>>
>>>>  Location: /People.html#tim
>>>>
>>>>which suggests that the user agent redirect to
>>>>"http://www.example.org/People.html#tim”
>>>>
>>>>
>>>>Likewise, a GET request generated for the URI reference
>>>>"http://www.example.org/index.html#larry"; might result in a 301
>>>>(Moved Permanently) response containing the header field:
>>>>
>>>>  Location: http://www.example.net/index.html
>>>>
>>>>which suggests that the user agent redirect to
>>>>"http://www.example.net/index.html#larry";, preserving the original
>>>>fragment identifier.
>>>>
>>>>
>>>>
>>>> This blog also explores the change.
>>>>
>>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>>>>
>>>>
>>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>>>>
>>>> "Browsers now re-append  fragments across 302 redirects unless they
>>>> are explicitly cleared this makes fragment encoding less safe than it was
>>>>  when originally specified" - thanks Jim. Looks like a good reason for
>>>> vetting this flow out.
>>>>
>>>> John,
>>>> Please provide more details/links about re-appending fragments.
>>>>
>>>> Thanks,
>>>> Oleg.
>>>>
>>>>
>>>> --
>>>> *From:* Jim Manico 
>>>> *To:* Oleg Gryb 
>>>> *Cc:* "oauth@ietf.org" ; Liyu Yi 
>>>> *Sent:* Thursday, June 30, 2016 10:25 PM
>>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as
>>>> Implicit grant
>>>>
>>>> Oleg! Hello! Great to see you pop up here with a similar concern.
>>>>
>>>> John Bradley just answered this thread with the details I was looking
>>>> for (thanks John, hat tip your way).
>>>>
>>>> He also mentioned details about fragment leakage:
>>>>
>>>&g

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

John,
Thanks, very useful. However, I'm still trying to figure out why it's 
dangerous. Fragment doesn't travel to a server in this new flow either. 
Appending it to Location header is done by the browser who needs to memorize 
what the original request was. If the original request had a fragment and the 
browser got redirected, Location header will be appended by the browser.
Are you saying that this is dangerous because the browser would *always* need 
to store the fragment somewhere in its memory just in case if a server decides 
to redirect?
So an attack vector here is that an imposter can try to retrieve the fragment 
from the browser's memory somehow. Is my understanding correct?
Oleg.


 
  From: John Bradley 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Friday, July 1, 2016 11:33 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
This behaviour started changing around 2011
>From HTTP/1.1See https://tools.ietf.org/html/rfc7231#section-7.1.2I      f the 
>Location value provided in a 3xx (Redirection) response does   not have a 
>fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"; might result in a 303 (See Other)
   response containing the header field:

 Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim”
   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"; might result in a 301
   (Moved Permanently) response containing the header field:

 Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry";, preserving the original
   fragment identifier.


This blog also explores the 
change.https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/


On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was  when 
originally specified" - thanks Jim. Looks like a good reason for vetting this 
flow out.
John,Please provide more details/links about re-appending fragments. 
Thanks,Oleg.

 
  From: Jim Manico 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Thursday, June 30, 2016 10:25 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
Oleg! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).
He also mentioned details about fragment leakage:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,--Jim Manico@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:


We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with POST would mean a significant performance impact in some high volume 
implementations (I think it was Goole folks who were saying this, but I don't 
remember now).
AFAIR, nobody was arguing about browsing history, so it's valid.
So, 6 years later we're at square one with this and I hope that this time the 
community will be more successful with getting rid of secrets in URL.
BTW, Jim, if you can come up with other scenarios when fragments can leak, 
please share. It'll probably help the community with solving this problem 
faster than in 6 years.
Thanks,Oleg.

 
      From: Jim Manico 
 To: Liyu Yi ; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
 > Shouldn’t it be more secure if we change to use a post method for access 
 > token, similar to the SAML does? I say yes. But please note I'm very new at 
 > this and someone with more experience will have more to say or correct my 
 > comments. Here are a few more details to consider.
  1) OAuth is a framework and not a standard, per se. Different authorization 
servers will have different implementations that are not necessarily compatible 
with other service provid

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

Yes but POST doesn't really work for in browser apps.

If it is a server app it should be using the code flow with GET or POST as
you like.

If we do a  post message based binding it will be targeted at in browser
applications.

John B.

On Fri, Jul 1, 2016 at 4:42 PM, Liyu Yi  wrote:

> BTW, I do not see any significant performance concerns for post. Parsing
> and executing the Javascript logic for post operation will be on the client
> side, no extra server load is introduced.
>
> Plus post will remove the size restriction of the URL length.
>
> -- Liyu
>
> On Fri, Jul 1, 2016 at 1:35 PM, Liyu Yi  wrote:
>
>> Thanks for the great comments and advices.
>>
>> I think it is a good idea for the working group to revise the fragment
>> part in the spec, since there might be public available tools already
>> implemented this approach and people can end up with a solution with
>> serious security loopholes.
>>
>> The re-append issue can be mitigate by a logic on Resource Server which
>> carefully re-writes/removes the fragment in any redirect, if the the
>> redirect can not be avoided.
>>
>> -- Liyu
>>
>>
>> On Fri, Jul 1, 2016 at 11:33 AM, John Bradley  wrote:
>>
>>> This behaviour started changing around 2011
>>>
>>> From HTTP/1.1
>>> See https://tools.ietf.org/html/rfc7231#section-7.1.2I
>>>   f the Location value provided in a 3xx (Redirection) response does
>>>
>>>not have a fragment component, a user agent MUST process the
>>>redirection as if the value inherits the fragment component of the
>>>URI reference used to generate the request target (i.e., the
>>>redirection inherits the original reference's fragment, if any).
>>>
>>>For example, a GET request generated for the URI reference
>>>"http://www.example.org/~tim"; might result in a 303 (See Other)
>>>response containing the header field:
>>>
>>>  Location: /People.html#tim
>>>
>>>which suggests that the user agent redirect to
>>>"http://www.example.org/People.html#tim”
>>>
>>>
>>>Likewise, a GET request generated for the URI reference
>>>"http://www.example.org/index.html#larry"; might result in a 301
>>>(Moved Permanently) response containing the header field:
>>>
>>>  Location: http://www.example.net/index.html
>>>
>>>which suggests that the user agent redirect to
>>>"http://www.example.net/index.html#larry";, preserving the original
>>>fragment identifier.
>>>
>>>
>>>
>>> This blog also explores the change.
>>>
>>> https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
>>>
>>>
>>> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
>>>
>>> "Browsers now re-append  fragments across 302 redirects unless they are
>>> explicitly cleared this makes fragment encoding less safe than it was  when
>>> originally specified" - thanks Jim. Looks like a good reason for vetting
>>> this flow out.
>>>
>>> John,
>>> Please provide more details/links about re-appending fragments.
>>>
>>> Thanks,
>>> Oleg.
>>>
>>>
>>> --
>>> *From:* Jim Manico 
>>> *To:* Oleg Gryb 
>>> *Cc:* "oauth@ietf.org" ; Liyu Yi 
>>> *Sent:* Thursday, June 30, 2016 10:25 PM
>>> *Subject:* Re: [OAUTH-WG] Security concern for URI fragment as Implicit
>>> grant
>>>
>>> Oleg! Hello! Great to see you pop up here with a similar concern.
>>>
>>> John Bradley just answered this thread with the details I was looking
>>> for (thanks John, hat tip your way).
>>>
>>> He also mentioned details about fragment leakage:
>>>
>>> "Browsers now re-append  fragments across 302 redirects unless they are
>>> explicitly cleared this makes fragment encoding less safe than it was when
>>> originally specified"
>>>
>>> Again, I'm new here but I'm grateful for this conversation.
>>>
>>> Aloha,
>>> --
>>> Jim Manico
>>> @Manicode
>>>
>>> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:
>>>
>>> We've discussed access tokens in URI back in 2010 (
>>> https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html).
>>> There were two major objectives when I

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

This behaviour started changing around 2011

From HTTP/1.1
See https://tools.ietf.org/html/rfc7231#section-7.1.2 
<https://tools.ietf.org/html/rfc7231#section-7.1.2>I
  f the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim"; might result in a 303 (See Other)
   response containing the header field:

 Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim”

   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry"; might result in a 301
   (Moved Permanently) response containing the header field:

 Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry";, preserving the original
   fragment identifier.


This blog also explores the change.
https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/
 
<https://blogs.msdn.microsoft.com/ieinternals/2011/05/16/url-fragments-and-redirects/>


> On Jul 1, 2016, at 1:05 PM, Oleg Gryb  wrote:
> 
> "Browsers now re-append  fragments across 302 redirects unless they are 
> explicitly cleared this makes fragment encoding less safe than it was  when 
> originally specified" - thanks Jim. Looks like a good reason for vetting this 
> flow out.
> 
> John,
> Please provide more details/links about re-appending fragments. 
> 
> Thanks,
> Oleg.
> 
> 
> From: Jim Manico 
> To: Oleg Gryb  
> Cc: "oauth@ietf.org" ; Liyu Yi 
> Sent: Thursday, June 30, 2016 10:25 PM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> Oleg! Hello! Great to see you pop up here with a similar concern.
> 
> John Bradley just answered this thread with the details I was looking for 
> (thanks John, hat tip your way).
> 
> He also mentioned details about fragment leakage:
> 
> "Browsers now re-append  fragments across 302 redirects unless they are 
> explicitly cleared this makes fragment encoding less safe than it was when 
> originally specified"
> 
> Again, I'm new here but I'm grateful for this conversation.
> 
> Aloha,
> --
> Jim Manico
> @Manicode
> 
> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  <mailto:oleg_g...@yahoo.com>> wrote:
> 
>> We've discussed access tokens in URI back in 2010 
>> (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html 
>> <https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html>). There 
>> were two major objectives when I was saying that it's not secure:
>> 
>> 1. Fragment is not sent to a server by a browser. When I've asked if this is 
>> true for every browser in the world, nobody was able to answer.
>> 2. Replacing with POST would mean a significant performance impact in some 
>> high volume implementations (I think it was Goole folks who were saying 
>> this, but I don't remember now).
>> 
>> AFAIR, nobody was arguing about browsing history, so it's valid.
>> 
>> So, 6 years later we're at square one with this and I hope that this time 
>> the community will be more successful with getting rid of secrets in URL.
>> 
>> BTW, Jim, if you can come up with other scenarios when fragments can leak, 
>> please share. It'll probably help the community with solving this problem 
>> faster than in 6 years.
>> 
>> Thanks,
>> Oleg.
>> 
>> 
>> From: Jim Manico mailto:j...@manicode.com>>
>> To: Liyu Yi mailto:liy...@gmail.com>>; oauth@ietf.org 
>> <mailto:oauth@ietf.org> 
>> Sent: Wednesday, June 29, 2016 7:30 AM
>> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
>> 
>> > Shouldn’t it be more secure if we change to use a post method for access 
>> > token, similar to the SAML does?
>> I say yes. But please note I'm very new at this and someone with more 
>> experience will have more to say or correct my comments.
>> Here are a few more details to consider.
>> 1) OAuth is a framework and not a standard, per se. Different authorization 
>> servers will have different implementations that are not necessarily 
>> compatible with other service providers. So there is no standard to break, 
>> p

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was  when 
originally specified" - thanks Jim. Looks like a good reason for vetting this 
flow out.
John,Please provide more details/links about re-appending fragments. 
Thanks,Oleg.

 
  From: Jim Manico 
 To: Oleg Gryb  
Cc: "oauth@ietf.org" ; Liyu Yi 
 Sent: Thursday, June 30, 2016 10:25 PM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
Oleg! Hello! Great to see you pop up here with a similar concern.
John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).
He also mentioned details about fragment leakage:
"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"
Again, I'm new here but I'm grateful for this conversation.
Aloha,--Jim Manico@Manicode
On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:


We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with POST would mean a significant performance impact in some high volume 
implementations (I think it was Goole folks who were saying this, but I don't 
remember now).
AFAIR, nobody was arguing about browsing history, so it's valid.
So, 6 years later we're at square one with this and I hope that this time the 
community will be more successful with getting rid of secrets in URL.
BTW, Jim, if you can come up with other scenarios when fragments can leak, 
please share. It'll probably help the community with solving this problem 
faster than in 6 years.
Thanks,Oleg.

 
  From: Jim Manico 
 To: Liyu Yi ; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
  
 > Shouldn’t it be more secure if we change to use a post method for access 
 > token, similar to the SAML does? I say yes. But please note I'm very new at 
 > this and someone with more experience will have more to say or correct my 
 > comments. Here are a few more details to consider.
  1) OAuth is a framework and not a standard, per se. Different authorization 
servers will have different implementations that are not necessarily compatible 
with other service providers. So there is no standard to break, per se.
  2) Sensitive data in a URI is a bad idea. They leak all over the place even 
over HTTPS. Even in fragments.
  3) Break the "rules" and find a way to submit sensitive data like access 
tokens, session information or any other (even short term) sensitive data in a 
secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other 
verbs - all over well configured HTTPS.
  4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE 
(with limited scopes/lifetimes) to provide message level confidentiality and 
integrity.
  Aloha,
 Jim Manico
Manicode Security
https://www.manicode.com 
 On 6/27/16 9:30 PM, Liyu Yi wrote:
  
  While we are working on a project with OAuth2 implementation, one question 
arises from our engineers. We noticed at 
https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified 
that    (C)  Assuming the resource owner grants access, the authorization   
  server redirects the user-agent back to the client using the     
redirection URI provided earlier.  The redirection URI includes     the 
access token in the URI fragment.   For my understanding, the browser keeps the 
URI fragment in the history, and this introduces unexpected exposure of the 
access token. A user without  authorization for the resource can get the access 
token as long as he has the access to the browser. This can happen in a shared 
computer in library, or for an IT staff who works on other employee’s computer. 
  Shouldn’t it be more secure if we change to use a post method for access 
token, similar to the SAML does? I feel there might be something I missed here. 
Any advices will be appreciated.  
  
 ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
 -- 
 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


   
 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


   
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Jim Manico]

Oleg! Hello! Great to see you pop up here with a similar concern.

John Bradley just answered this thread with the details I was looking for 
(thanks John, hat tip your way).

He also mentioned details about fragment leakage:

"Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified"

Again, I'm new here but I'm grateful for this conversation.

Aloha,
--
Jim Manico
@Manicode

> On Jul 1, 2016, at 1:24 AM, Oleg Gryb  wrote:
> 
> We've discussed access tokens in URI back in 2010 
> (https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There 
> were two major objectives when I was saying that it's not secure:
> 
> 1. Fragment is not sent to a server by a browser. When I've asked if this is 
> true for every browser in the world, nobody was able to answer.
> 2. Replacing with POST would mean a significant performance impact in some 
> high volume implementations (I think it was Goole folks who were saying this, 
> but I don't remember now).
> 
> AFAIR, nobody was arguing about browsing history, so it's valid.
> 
> So, 6 years later we're at square one with this and I hope that this time the 
> community will be more successful with getting rid of secrets in URL.
> 
> BTW, Jim, if you can come up with other scenarios when fragments can leak, 
> please share. It'll probably help the community with solving this problem 
> faster than in 6 years.
> 
> Thanks,
> Oleg.
> 
> 
> From: Jim Manico 
> To: Liyu Yi ; oauth@ietf.org 
> Sent: Wednesday, June 29, 2016 7:30 AM
> Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
> 
> > Shouldn’t it be more secure if we change to use a post method for access 
> > token, similar to the SAML does?
> I say yes. But please note I'm very new at this and someone with more 
> experience will have more to say or correct my comments.
> Here are a few more details to consider.
> 1) OAuth is a framework and not a standard, per se. Different authorization 
> servers will have different implementations that are not necessarily 
> compatible with other service providers. So there is no standard to break, 
> per se.
> 2) Sensitive data in a URI is a bad idea. They leak all over the place even 
> over HTTPS. Even in fragments.
> 3) Break the "rules" and find a way to submit sensitive data like access 
> tokens, session information or any other (even short term) sensitive data in 
> a secure fashion. This includes POST, JSON data payloads over PUT/PATCH and 
> other verbs - all over well configured HTTPS.
> 4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE 
> (with limited scopes/lifetimes) to provide message level confidentiality and 
> integrity.
> Aloha,
> Jim Manico
> Manicode Security
> https://www.manicode.com
> 
>> On 6/27/16 9:30 PM, Liyu Yi wrote:
>> While we are working on a project with OAuth2 implementation, one question 
>> arises from our engineers.
>> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it 
>> is specified that
>>   
>> (C)  Assuming the resource owner grants access, the authorization
>> server redirects the user-agent back to the client using the
>> redirection URI provided earlier.  The redirection URI includes
>> the access token in the URI fragment.
>>  
>> For my understanding, the browser keeps the URI fragment in the history, and 
>> this introduces unexpected exposure of the access token. A user without 
>> authorization for the resource can get the access token as long as he has 
>> the access to the browser. This can happen in a shared computer in library, 
>> or for an IT staff who works on other employee’s computer.
>>  
>> Shouldn’t it be more secure if we change to use a post method for access 
>> token, similar to the SAML does?
>> I feel there might be something I missed here. Any advices will be 
>> appreciated.
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> -- 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Oleg Gryb]

We've discussed access tokens in URI back in 2010 
(https://www.ietf.org/mail-archive/web/oauth/current/msg04043.html). There were 
two major objectives when I was saying that it's not secure:
1. Fragment is not sent to a server by a browser. When I've asked if this is 
true for every browser in the world, nobody was able to answer.2. Replacing 
with POST would mean a significant performance impact in some high volume 
implementations (I think it was Goole folks who were saying this, but I don't 
remember now).
AFAIR, nobody was arguing about browsing history, so it's valid.
So, 6 years later we're at square one with this and I hope that this time the 
community will be more successful with getting rid of secrets in URL.
BTW, Jim, if you can come up with other scenarios when fragments can leak, 
please share. It'll probably help the community with solving this problem 
faster than in 6 years.
Thanks,Oleg.

 
  From: Jim Manico 
 To: Liyu Yi ; oauth@ietf.org 
 Sent: Wednesday, June 29, 2016 7:30 AM
 Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant
   
 > Shouldn’t it be more secure if we change to use a post method for access 
 > token, similar to the SAML does? I say yes. But please note I'm very new at 
 > this and someone with more experience will have more to say or correct my 
 > comments. Here are a few more details to consider.
  1) OAuth is a framework and not a standard, per se. Different authorization 
servers will have different implementations that are not necessarily compatible 
with other service providers. So there is no standard to break, per se.
  2) Sensitive data in a URI is a bad idea. They leak all over the place even 
over HTTPS. Even in fragments.
  3) Break the "rules" and find a way to submit sensitive data like access 
tokens, session information or any other (even short term) sensitive data in a 
secure fashion. This includes POST, JSON data payloads over PUT/PATCH and other 
verbs - all over well configured HTTPS.
  4) If you really must submit sensitive data over GET , consider JWT/JWS/JWE 
(with limited scopes/lifetimes) to provide message level confidentiality and 
integrity.
  Aloha,
 Jim Manico
Manicode Security
https://www.manicode.com 
 On 6/27/16 9:30 PM, Liyu Yi wrote:
  
  While we are working on a project with OAuth2 implementation, one question 
arises from our engineers. We noticed at 
https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is specified 
that    (C)  Assuming the resource owner grants access, the authorization   
  server redirects the user-agent back to the client using the     
redirection URI provided earlier.  The redirection URI includes     the 
access token in the URI fragment.   For my understanding, the browser keeps the 
URI fragment in the history, and this introduces unexpected exposure of the 
access token. A user without  authorization for the resource can get the access 
token as long as he has the access to the browser. This can happen in a shared 
computer in library, or for an IT staff who works on other employee’s computer. 
  Shouldn’t it be more secure if we change to use a post method for access 
token, similar to the SAML does? I feel there might be something I missed here. 
Any advices will be appreciated.  
  
 ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
 
 -- 
 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


   
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[John Bradley]

I agree with Justin.

You should be using the code flow if it is a server based client.

The OAuth WG is considering better alternatives to using fragment encoding for 
in browser JS clients as well.  
For the moment the only standard for the in browser client is fragment 
encoding.  In the future we hope to have more modern methods based on post 
message.

For people using openID Connect who want a id_token in the front channel 
(Hybrid flow) they should use the form post response mode
 https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html 


Browsers now re-append  fragments across 302 redirects unless they are 
explicitly cleared this makes fragment encoding less safe than it was when 
originally specified.

John B.

> On Jun 29, 2016, at 10:30 AM, Justin Richer  wrote:
> 
> The implicit flow was designed for in-browser clients that don’t have a 
> server back-end. In these cases, keeping the data inside the browser entirely 
> is exactly the goal: you don’t want to use query or form parameters because 
> those get sent by the browser back to the server. That was the idea anyway, 
> except that now new versions of Chrome also send the fragment back (as I 
> understand things) so we’re in a bit of a lurch with our assumed security 
> model. 
> 
> Even so, you’re absolutely right that the fragment can leak all over the 
> browser. There are a few tricks you can do to mitigate this, like messing 
> about with the history, but they’re patches at best. This is why the implicit 
> flow is considered fairly insecure by most people in the community, and it 
> really needs to be used only in the very limited context of an in-browser 
> application, with limited lifetime access tokens (perhaps even tied to a live 
> session at the AS). What you’re doing with the implicit flow, when used 
> properly, is really more like a cross-domain session sharing.
> 
>  — Justin
> 
>> On Jun 27, 2016, at 3:30 PM, Liyu Yi > > wrote:
>> 
>> While we are working on a project with OAuth2 implementation, one question 
>> arises from our engineers.
>> 
>> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 
>> , it is 
>> specified that
>> 
>>   
>> (C)  Assuming the resource owner grants access, the authorization
>> 
>> server redirects the user-agent back to the client using the
>> 
>> redirection URI provided earlier.  The redirection URI includes
>> 
>> the access token in the URI fragment.
>> 
>>  
>> For my understanding, the browser keeps the URI fragment in the history, and 
>> this introduces unexpected exposure of the access token. A user without 
>> authorization for the resource can get the access token as long as he has 
>> the access to the browser. This can happen in a shared computer in library, 
>> or for an IT staff who works on other employee’s computer.
>> 
>>  
>> Shouldn’t it be more secure if we change to use a post method for access 
>> token, similar to the SAML does?
>> 
>> I feel there might be something I missed here. Any advices will be 
>> appreciated.
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Justin Richer]

The implicit flow was designed for in-browser clients that don’t have a server 
back-end. In these cases, keeping the data inside the browser entirely is 
exactly the goal: you don’t want to use query or form parameters because those 
get sent by the browser back to the server. That was the idea anyway, except 
that now new versions of Chrome also send the fragment back (as I understand 
things) so we’re in a bit of a lurch with our assumed security model. 

Even so, you’re absolutely right that the fragment can leak all over the 
browser. There are a few tricks you can do to mitigate this, like messing about 
with the history, but they’re patches at best. This is why the implicit flow is 
considered fairly insecure by most people in the community, and it really needs 
to be used only in the very limited context of an in-browser application, with 
limited lifetime access tokens (perhaps even tied to a live session at the AS). 
What you’re doing with the implicit flow, when used properly, is really more 
like a cross-domain session sharing.

 — Justin

> On Jun 27, 2016, at 3:30 PM, Liyu Yi  wrote:
> 
> While we are working on a project with OAuth2 implementation, one question 
> arises from our engineers.
> 
> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 
> , it is specified 
> that
> 
>   
> (C)  Assuming the resource owner grants access, the authorization
> 
> server redirects the user-agent back to the client using the
> 
> redirection URI provided earlier.  The redirection URI includes
> 
> the access token in the URI fragment.
> 
>  
> For my understanding, the browser keeps the URI fragment in the history, and 
> this introduces unexpected exposure of the access token. A user without 
> authorization for the resource can get the access token as long as he has the 
> access to the browser. This can happen in a shared computer in library, or 
> for an IT staff who works on other employee’s computer.
> 
>  
> Shouldn’t it be more secure if we change to use a post method for access 
> token, similar to the SAML does?
> 
> I feel there might be something I missed here. Any advices will be 
> appreciated.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Jim Manico]

> Shouldn’t it be more secure if we change to use a post method for
access token, similar to the SAML does?

I say yes. But please note I'm very new at this and someone with more
experience will have more to say or correct my comments.

Here are a few more details to consider.

1) OAuth is a framework and not a standard, per se. Different
authorization servers will have different implementations that are not
necessarily compatible with other service providers. So there is no
standard to break, per se.

2) Sensitive data in a URI is a bad idea. They leak all over the place
even over HTTPS. Even in fragments.

3) Break the "rules" and find a way to submit sensitive data like access
tokens, session information or any other (even short term) sensitive
data in a secure fashion. This includes POST, JSON data payloads over
PUT/PATCH and other verbs - all over well configured HTTPS.

4) If you really must submit sensitive data over GET , consider
JWT/JWS/JWE (with limited scopes/lifetimes) to provide message level
confidentiality and integrity.

Aloha,

Jim Manico
Manicode Security
https://www.manicode.com


On 6/27/16 9:30 PM, Liyu Yi wrote:
>
> While we are working on a project with OAuth2 implementation, one
> question arises from our engineers.
>
> We noticed at
> https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30, it is
> specified that
>
>   
>
> (C)  Assuming the resource owner grants access, the authorization
>
> server redirects the user-agent back to the client using the
>
> redirection URI provided earlier.  The redirection URI includes
>
> the access token in the URI fragment.
>
>  
>
> For my understanding, the browser keeps the URI fragment in the
> history, and this introduces unexpected exposure of the access token.
> A user without authorization for the resource can get the access token
> as long as he has the access to the browser. This can happen in a
> shared computer in library, or for an IT staff who works on other
> employee’s computer.
>
>  
>
> Shouldn’t it be more secure if we change to use a post method for
> access token, similar to the SAML does?
>
> I feel there might be something I missed here. Any advices will be
> appreciated.
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

[Thomas Broyer]

The client app could (and should) do a window.location.replace or
window.history.replaceState to remove the entry from the browser history.
AFAICT, this is out of scope of the OAuth specs because they're about the
protocol and interactions between the parties involved, not about securing
each one on its own.

That said, if the computer is shared between users, they should take care
of properly signing out, which should (in most cases) revoke tokens and, in
the case of client apps should also involve explicitly revoking the tokens
they've been handed out. So even if a token is present in the browser
history it shouldn't be usable. If the previous user hasn't signed out,
then he has bigger problems.

See also https://tools.ietf.org/html/rfc6819#section-4.4.2.2

As for the form post, see
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

On Wed, Jun 29, 2016 at 4:08 PM Liyu Yi  wrote:

> While we are working on a project with OAuth2 implementation, one question
> arises from our engineers.
>
> We noticed at https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30,
> it is specified that
>
>
>
> (C)  Assuming the resource owner grants access, the authorization
>
> server redirects the user-agent back to the client using the
>
> redirection URI provided earlier.  The redirection URI includes
>
> the access token in the URI fragment.
>
>
>
> For my understanding, the browser keeps the URI fragment in the history,
> and this introduces unexpected exposure of the access token. A user without
> authorization for the resource can get the access token as long as he has
> the access to the browser. This can happen in a shared computer in library,
> or for an IT staff who works on other employee’s computer.
>
>
>
> Shouldn’t it be more secure if we change to use a post method for access
> token, similar to the SAML does?
>
> I feel there might be something I missed here. Any advices will be
> appreciated.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth