Re: [OAUTH-WG] Confusion on Implicit Grant flow

[Bill Burke <[e-mail]>]

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
> <[e-mail]
> <mailto:[e-mail]>> 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com