uth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
Typically the implicit callback JS is part of the application that is already
loaded and cached in the browser.
The implicit flow doesn’t depend on on the fragment not being re-appended to
the resource locat
.@ietf.org]*On Behalf Of*John Bradley
*Sent:*Monday, February 09, 2015 3:31 PM
*To:*Prateek Mishra
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] Confusion on Implicit Grant flow
Typically the implicit callback JS is part of the application that is
already loaded and c
y 09, 2015 3:31 PM
> To: Prateek Mishra
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
>
> Typically the implicit callback JS is part of the application that is already
> loaded and cached in the browser.
>
> The implicit flow doesn’t depend
lf Of John Bradley
Sent: Monday, February 09, 2015 3:31 PM
To: Prateek Mishra
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
Typically the implicit callback JS is part of the application that is already
loaded and cached in the browser.
The implicit flow doesn't d
The nonce allows the client to insert a unique value into the id_token to
associate it with a particular browser session(Think SAML RequstID).
That is useful for web server based clients. It may or may not be useful in
the JS case, as the client is the browser.
While code can only be used o
On 2/10/2015 8:15 AM, John Bradley wrote:
The issue is maintaining key material in the browser.
Web Crypto will help with that , but is not deployed widely in browsers at the
moment.
Thinking about it a bit someone could make a more secure flow for JS clients
using code and some Connect ext
The code and implicit response_type are defined in RFC 6749.
https://tools.ietf.org/html/rfc6749#section-4.1.2
https://tools.ietf.org/html/rfc6749#section-4.2.2
It describes one way to encode the response in each case with no mention of
that being extended. In the text there is no normative M
On 2/10/2015 7:06 AM, Brian Campbell wrote:
On Mon, Feb 9, 2015 at 3:59 PM, John Bradley mailto:ve7...@ve7jtb.com>> wrote:
Connect has a response_mode that allows the response to be form
encoded rather than fragment.
I read RFC 5849 as only allowing code to be query encoded. Th
The issue is maintaining key material in the browser.
Web Crypto will help with that , but is not deployed widely in browsers at the
moment.
Thinking about it a bit someone could make a more secure flow for JS clients
using code and some Connect extensions now.
If I were concerned about loggin
On Mon, Feb 9, 2015 at 3:59 PM, John Bradley wrote:
> Connect has a response_mode that allows the response to be form encoded
> rather than fragment.
> I read RFC 5849 as only allowing code to be query encoded. The
> response_mode was intended for the new response types we defined in
> http://o
Hi John
On 09/02/15 22:59, John Bradley wrote:
The security problem was people only doing host name matching on redirect_uri
and attackers finding redirectors to use. That impacted all public clients
not just implicit.
Implicit took most of the heat because that was what Facebook was using, a
The security problem was people only doing host name matching on redirect_uri
and attackers finding redirectors to use. That impacted all public clients
not just implicit.
Implicit took most of the heat because that was what Facebook was using, and
they had the largest issue.
Connect has a
urity section of RFC 6749.
E. Anwar Reddick
Research Scientist
Georgia Tech Research Institute
- Reply message -
From: "Bill Burke"
To: "John Bradley"
Cc: "oauth@ietf.org"
Subject: [OAUTH-WG] Confusion on Implicit Grant flow
Date: Mon, Feb 9, 2015 5:33 PM
On 2/9/2015 5:03 PM, John Bradley wrote:
OK, I don't know if the WG has discussed the issue of fragments in browser
history.
So you are trading off several round trips against the possibility of a token
leaking in browser history or bookmark?
Yes, bookmarking tokens is a little scary, IMO
OK, I don't know if the WG has discussed the issue of fragments in browser
history.
So you are trading off several round trips against the possibility of a token
leaking in browser history or bookmark?
One extension that Connect introduced was a "code id_token" response type that
is fragment
For implicit flow, wouldn't the token be available in the browser
history and could also possibly be bookmarked by accident or on purpose?
If a code is bookmarked, so what? It is only valid for a tiny window
(milliseconds).
Please tell me how a code is more likely to be leaked without a clie
Typically the implicit callback JS is part of the application that is already
loaded and cached in the browser.
The implicit flow doesn’t depend on on the fragment not being re-appended to
the resource location URI in the 302. It would admittedly be more secure if
that didn’t happen.
Re-appe
The implicit flow depends upon a subtle and little known aspect of
browser behavior - that the URI fragment component isn't propagated
across redirects.
I havent checked this recently - but I am aware that several folks have
found that some browser versions dont comply with this requirement.
You are passing code in a query parameter, and without a secret that is more
likely to be leaked than sending token in the fragment directly from the
authorization endpoint to the browser JS in a fragment.
You have several extra round trips for no security benefit. In your case the
code in th
If you don't have a client secret, why is Javascript-based auth code
grant flow more risky? We also require SSL and valid redirect URI
patterns to be registered for the application. The code can only ever
be sent to specific URLs and can only be used once. CORS origin
validation is also an e
If you don't have a client secret, or are storing the the client secret in the
Javascrypt, then you are probably more at risk using code than implicit.
Implicit is risky because running a OAuth client in the browser is risky.
Using code in that case makes it no better, and arguably worse.
Perh
Due to the security risks of implicit Grant flow, our Javascript adapter
only supports Auth Code Grant flow. Our IDP has an extra step of
allowing you to specify a valid CORS origin for an application. Anybody
see any problems with this kind of approach? Implicit Grant Flow just
seemed real
Hi Adam,
I'm not 100% sure what you're envisioning as an alternative to the implicit
flow, but if I'm reading between the lines of your question correctly,
there are two key parts to the answer, because the implicit flow is
designed to accomplish two key goals (vs. the authorization code grant):
It isn’t an extra step, the call back via 302 has to be to a URI in the
location header. The JS loaded by that URI may already be cached in the
browser as part of the APP.
The cached JS typically extracts the token and uses it. The token is never
passed to the server where the JS is loaded f
Hi,
Having spent most of my time with native apps and web apps, I now am looking at
use cases where I need to implement a user-agent-based app. The Implicit flow
seems to be optimized for this.
To test my understanding, this flow is for a JavaScript client (or similar)
executing within a web
25 matches
Mail list logo
