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> 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> 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> 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> 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> 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> 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
