I am making a distinction between a browser talking to a Web server that is acting as a OAuth Client POST response mode = good , and a oauth client running in the browser user agent as a Java script application (that can’t directly capture a POST response back to the server)
So it depends on where the client is actually running. Are you saying that you are using a 302 redirect from the authorization endpoint back to the server hosting the JS and then loading the JS including the code and then using CORES to exchange the code for a AT? You can do that but I don’t think a public client like that is more secure than just using the fragment encoded response and is more work. It also may give the server a false sense of security. John B. > On Jul 1, 2016, at 5:52 PM, Josh Mandel <jman...@gmail.com> 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 <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> 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 <jman...@gmail.com >> <mailto:jman...@gmail.com>> 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 <ve7...@ve7jtb.com >> <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 <jman...@gmail.com >>> <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 <oleg_g...@yahoo.com >>> <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 <jric...@mit.edu <mailto:jric...@mit.edu>> >>> To: Josh Mandel <jman...@gmail.com <mailto:jman...@gmail.com>> >>> Cc: Oleg Gryb <o...@gryb.info <mailto:o...@gryb.info>>; "<oauth@ietf.org >>> <mailto:oauth@ietf.org>>" <oauth@ietf.org <mailto:oauth@ietf.org>>; Liyu Yi >>> <liy...@gmail.com <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 <jman...@gmail.com >>>> <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 <ve7...@ve7jtb.com >>> <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 <liy...@gmail.com >>> <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 <liy...@gmail.com >>> <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 <ve7...@ve7jtb.com >>> <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 <oleg_g...@yahoo.com >>>> <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 <j...@manicode.com <mailto:j...@manicode.com>> >>>> To: Oleg Gryb <o...@gryb.info <mailto:o...@gryb.info>> >>>> Cc: "oauth@ietf.org <mailto:oauth@ietf.org>" <oauth@ietf.org >>>> <mailto:oauth@ietf.org>>; Liyu Yi <liy...@gmail.com >>>> <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 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 >>>> <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 <j...@manicode.com <mailto:j...@manicode.com>> >>>>> To: Liyu Yi <liy...@gmail.com <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, 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 >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> -- >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
