Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Here is actually some idea. John, please let me know if there is anything wrong with this. 1. At step "C" Auth Server instead of serving a redirect will return a payload in a response with a JS  called on page load that will do the redirect. Something like below where I use JsRender, but it can b

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

You know, I've tried to solve this problem 6 years ago and I failed, but I'm glad that community is looking to this again and I hope that John and others will eventually come up with something better than what we have now. If I come up with a sane idea, I'll definitely share. From: Liy

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

As John has already pointed out - you're confusing RS with the web-hosted client resource. From: Liyu Yi To: John Bradley Cc: Oleg Gryb ; "" Sent: Friday, July 1, 2016 6:11 PM Subject: Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant I would say AT is supposed

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

yes > On Jul 1, 2016, at 8:39 PM, Oleg Gryb wrote: > > I think, the intention was not to share AT with the web-hosted client > resource. As you can see in the original flow the latter never receives the > AT, it simply provides code that can get AT from a fragment and some UI. In > the modifie

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

I think, the intention was not to share AT with the web-hosted client resource. As you can see in the original flow the latter never receives the AT, it simply provides code that can get AT from a fragment and some UI. In the modified flow AT is sent to the web-hosted client resource, which make

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 wrote: > > John, > > I am a little bit confused :) > Are you talking about a SPA type of clie

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 st

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

If the in browser JS checks that it is talking to the correct AS making a authorization request that is no worse that making a request to exchange code via CORS. Attacks where code is stolen and replayed to the client to impersonate the user are also possable That is the reason for the id_token

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

I'm aware about exploits related to improper redirect_url validation, which was FB case, no qs here,  but I still can't understand if appending a fragment to Location by a browser makes this exploit simpler or can lead to other exploits that have not been described yet. From: John Brad

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

HTTP POST requests are also a lot more difficult to cache server side compared to URI's which are easier to cache. I'm likely not explaining this well, but I believe it's a webscale concern. -- Jim Manico @Manicode > On Jul 1, 2016, at 11:01 PM, Oleg Gryb wrote: > > AFAIR, they were talking a

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 wh

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 perspec

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 need

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

If the attacker can modify the redirect URI to anything like an embedded add that will do a 302 redirect then the recipient of the redirect can load JS to extract the access token. This has happened at Facebook so many times I have lost count. It is not theoretical, it happens all the time. O

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 au

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

Justin is correct. They may have been trying to avoid the client POST to the token endpoint with the code. That is a separate issue from the question of using a fragment encoded GET 302 or a JS POST redirect to return from the authorization endpoint. The response via the browser is smaller a

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 browserWhy 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 To: Jo

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

AFAIR, they were talking about cost of this additional POST on the server side, which was not good for high volume traffic (millions requests per day). I'll try to dig it out to find more details. From: Liyu Yi To: John Bradley Cc: Oleg Gryb ; Jim Manico ; "oauth@ietf.org" Sent:

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,

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 wrote: > Yes but POST doesn't really work for in browser apps. > > If it

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

John, Thanks, very useful. However, I'm still trying to figure out why it's dangerous. Fragment doesn't travel to a server in this new flow either. Appending it to Location header is done by the browser who needs to memorize what the original request was. If the original request had a fragment a

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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 wrote: > BTW, I do

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

This behaviour started changing around 2011 From HTTP/1.1 See 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

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

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

Re: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07

Thanks, I will try and get to the changes before the cut off. John B. > On Jun 29, 2016, at 9:57 AM, Hannes Tschofenig > wrote: > > Hi Nat, Hi John, > > thanks for your work on draft-ietf-oauth-jwsreq. I would like to get the > document ready for the IESG and have therefore reviewed it. > >