No not if it is a GET back to the same URI that loaded the JS and it is cashed. At least that was the design by Facebook, Google and other at the time.
John B. > On Jul 1, 2016, at 7:26 PM, Liyu Yi <liy...@gmail.com> wrote: > > John, > > I am a little bit confused :) > Are you talking about a SPA type of client application and concerning the > POST will reload the browser DOM from the RS domain? If that is the case, > even the current spec using a redirect with fragment in URL will have the > same behavior, right? > > On Fri, Jul 1, 2016 at 4:06 PM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > 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 <liy...@gmail.com >> <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 token over, but I do not >> see why get it need that compexity. >> >> >> On Fri, Jul 1, 2016 at 3:13 PM, Josh Mandel <jman...@gmail.com >> <mailto:jman...@gmail.com>> 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 said, I wasn't aiming to discuss the relative security; just wanted to >> make sure I knew what you meant by "won't work well". >> >> Thanks again! >> >> -Josh >> >> On Jul 1, 2016 18:02, "John Bradley" <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> wrote: >> 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 >>> <mailto: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
