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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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]> 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]> >>>>>> *To:* Josh Mandel <[email protected]> >>>>>> *Cc:* Oleg Gryb <[email protected]>; "<[email protected]>" <[email protected]>; >>>>>> Liyu Yi <[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]> 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 <[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]> 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]> 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]> >>>>>> 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 <[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]> >>>>>> *To:* Oleg Gryb <[email protected]> >>>>>> *Cc:* "[email protected]" <[email protected]>; Liyu Yi <[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]> 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 <[email protected]> >>>>>> *To:* Liyu Yi <[email protected]>; [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 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 >>>>>> [email protected]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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>> >>>> >>> >>> > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
