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 <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 <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 <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 <jric...@mit.edu> >> *To:* Josh Mandel <jman...@gmail.com> >> *Cc:* Oleg Gryb <o...@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>; >> Liyu Yi <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 <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) isn't >> universal, or something more? >> >> On Fri, Jul 1, 2016 at 4:51 PM, John Bradley <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 <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 <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 <ve7...@ve7jtb.com> 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 <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 <j...@manicode.com> >> *To:* Oleg Gryb <o...@gryb.info> >> *Cc:* "oauth@ietf.org" <oauth@ietf.org>; Liyu Yi <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 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 <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). >> 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 <j...@manicode.com> >> *To:* Liyu Yi <liy...@gmail.com>; 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 Securityhttps://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, 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 listOAuth@ietf.orghttps://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 >> >> >> _______________________________________________ >> 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
