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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
