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
