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 makes security worse in my
view, because you have your AT exposed in two places now - in the User Agent
*and* in the web-hosted client resource.
From: John Bradley <ve7...@ve7jtb.com>
To: Liyu Yi <liy...@gmail.com>
Cc: Oleg Gryb <o...@gryb.info>; "<oauth@ietf.org>" <oauth@ietf.org>
Sent: Friday, July 1, 2016 4:06 PM
Subject: 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 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> 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. 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! -JoshOn 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 ), 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 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 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 <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.1See 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 Security
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, 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
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
_______________________________________________
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
