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 extra step we do to ensure a rogue javascript app
isn't making any code-to-token requests.
I'm just trying to figure out if we missed anything...
On 2/9/2015 3:16 PM, John Bradley wrote:
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.
Perhaps I don't understand the environment.
John B.
On Feb 9, 2015, at 5:05 PM, Bill Burke <bbu...@redhat.com> wrote:
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 really risky to even
support as a protocol.
On 2/6/2015 4:40 PM, Josh Mandel wrote:
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):
1. Shave off one round-trip HTTP request (the step of exchanging a code
for a token)
2. Avoid unnecessarily leading the token to the client's back-end web server
Goal 1 is straightforward. For goal 2: OAuth2's implicit flow takes
advantage of the fact that a URL's "#hash" is not sent to the server
with an HTTP request. By embedding the token in a "#hash", it won't
inadvertently appear in server logs, for example. So with the implicit
flow, I can (for example) statically host a browser-based app at Amazon
S3 without having access tokens leak to Amazon. (Of course, if your
threat model includes a compromised server, then bets are off on this
point.)
Hope this helps,
-Josh
On Fri, Feb 6, 2015 at 1:27 PM, Adam Lewis
<adam.le...@motorolasolutions.com
<mailto:adam.le...@motorolasolutions.com>> wrote:
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 browser.____
__ __
At step (a) the client directs the UA to the authorization server,
but the authorization server redirects the UA to a web-hosted client
resource. Why? It says so that the web-hosted client resources can
push javascript (or other) back into the UA so it can extract the
access token in the fragment; but some sort of javascript is already
running in the browser, since it initiated the authorization request
in the first place. So why this extra step? Why not treat the
javascript client running in the UA like a native app and handle the
redirect uri?____
__ __
I know this was well thought out when the spec was written, so
trying to figure out what I’m missing?____
__ __
__ __
__ __
Tx!
adam____
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
