To: Prateek Mishra
Cc: oauth@ietf.orgmailto: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
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 depend
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
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
@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 location URI in the 302
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,
On 2/10/2015 7:06 AM, Brian Campbell wrote:
On Mon, Feb 9, 2015 at 3:59 PM, John Bradley ve7...@ve7jtb.com
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
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
[mailto:oauth-boun...@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
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
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
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.
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
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
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.
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
section of RFC 6749.
E. Anwar Reddick
Research Scientist
Georgia Tech Research Institute
- Reply message -
From: Bill Burke bbu...@redhat.com
To: John Bradley ve7...@ve7jtb.com
Cc: oauth@ietf.org oauth@ietf.org
Subject: [OAUTH-WG] Confusion on Implicit Grant flow
Date: Mon, Feb 9, 2015 5
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
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
19 matches
Mail list logo
