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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> > To: Josh Mandel <[email protected] <mailto:[email protected]>> > Cc: Oleg Gryb <[email protected] <mailto:[email protected]>>; "<[email protected] > <mailto:[email protected]>>" <[email protected] <mailto:[email protected]>>; Liyu Yi > <[email protected] <mailto:[email protected]>> > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >> To: Oleg Gryb <[email protected] <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>; Liyu Yi <[email protected] >> <mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> >>> To: Liyu Yi <[email protected] <mailto:[email protected]>>; [email protected] >>> <mailto:[email protected]> >>> 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 <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>https://tools.ietf.org/html/draft-ietf-oauth-v2-31#page-30 >>>> <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 >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> -- >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> > > > > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
