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

[John Bradley <[e-mail]>]

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