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

Prateek Mishra Tue, 10 Feb 2015 10:46:28 -0800

We use a simpler flow that isn't as open-ended as the implicit flow.

The JS client uses a XMLHttpRequest call to exchange the browser cookiefor an access token to the desired resource(this can be modeled via the Assertion Framework specification, with thecookie acting as the authorization grant).

The JS client subsequently uses the access token to interact with theresource server.


- prateek

Inline

On Feb 10, 2015, at 1:12 PM, Adam Lewis<adam.le...@motorolasolutions.com<mailto:adam.le...@motorolasolutions.com>> wrote:
Hi John,
What do you mean by the app that is “already loaded and cached in thebrowser?” Where did this app come from initially? Is this whatcomes from the web-hosted client resource in step D/E of section4.2? So the first time D/E **will** flow over the wire, and in allsubsequent requests it will be cached?

Yes the web hosted client resource is typically the same JS code thatis creating the Authorization request in A. Now that you mention itthe diagram in 4.2 is ambiguous about where that request comes from ,the fact that it is coming from the browser implies that it is a JSCORS type request.

In some cases you might have a webserver invoke it via a 302 redirectand load a new JS app from the redirect URI.The important thing is that the fragment is not sent to the server onthe call that loads the JS even if it is not cached.

The thing people do (facebook and others) that is twisting implicit inmy opinion is having the callback URI just load a JS snipppet thatextracts the token and posts it back to “Web hosted client resource”

Those applications should be using the code flow.

And with respect to the web hosted client resource, is this aresource deployed by the same domain as the RS to facilitate thedeployment of user-agent-based apps to access the APIs exposed bythat RS?

The hosted client resource is typically a AJAX/AngularJS applicationthat doesn’t want to swap out it’s context by doing a full 302redirect to the AS.


The AS and RS could be completely separate from the client.

However it is not uncommon for people developing AngularJS apps toprotect the API that they use with OAuth, in that case they may all befrom the same domain.

It might be that a sophisticated app may have multiple tokens fordifferent API across multiple providers.


John B.

adam
*From:*OAuth [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 isalready loaded and cached in the browser.The implicit flow doesn’t depend on on the fragment not beingre-appended to the resource location URI in the 302. It wouldadmittedly be more secure if that didn’t happen.Re-appending the fragment is the correct browser behaviour accordingto the W3C.I still think you are farther ahead with that than leaking the codein the referrer.Implicit if done correctly has the token in one leg. code on theother hand has the code in 4 legs and the token in one.It is having the JS make the exchange of code for the AT without asecret that is the problem in my opinion.If the client is a server that is doing the code -> token exchangethen the answer is different, but the question was for a JS only client.

John B.

    On Feb 9, 2015, at 6:21 PM, Prateek Mishra
    <prateek.mis...@oracle.com <mailto:prateek.mis...@oracle.com>> wrote:
    The implicit flow depends upon a subtle and little known aspect
    of browser behavior - that the URI fragment component isn't
    propagated across redirects.

    I havent checked this recently - but I am aware that several
    folks have found that some browser versions dont comply with this
    requirement.
    
http://weblog.bulknews.net/post/85008516879/covert-redirect-vulnerability-with-oauth-2

    The additional round-trip issue is also unclear. The implicit
    flow requires an additional redirect (round-trip) to retrieve JS
    which retrieves the access token from the fragment URI.

    How is that different from a HTTPs callback to exchange the
    access code for the access token?

    - prateek


    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 the query parameter goes from the browser to the redirect endpoint 
then must be sent back to the browser, and then to the token endpoint.

    So yes using code for that is less secure.

    Both rely solely on the registered redirect URI for security, but implicit 
has fewer hopes and is more friendly to JS.

    John B.

        On Feb 9, 2015, at 5:50 PM, Bill Burke<bbu...@redhat.com>  
<mailto:bbu...@redhat.com>  wrote:

        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>  
<mailto: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>

                    <mailto: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>  
<mailto:OAuth@ietf.org>  <mailto:OAuth@ietf.org>

                        https://www.ietf.org/mailman/listinfo/oauth

                    _______________________________________________

                    OAuth mailing list

                    OAuth@ietf.org  <mailto:OAuth@ietf.org>

                    https://www.ietf.org/mailman/listinfo/oauth

                --

                Bill Burke

                JBoss, a division of Red Hat

                http://bill.burkecentral.com  <http://bill.burkecentral.com/>

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org  <mailto:OAuth@ietf.org>

                https://www.ietf.org/mailman/listinfo/oauth

--

        Bill Burke

        JBoss, a division of Red Hat

        http://bill.burkecentral.com  <http://bill.burkecentral.com/>




    _______________________________________________

    OAuth mailing list

    OAuth@ietf.org  <mailto:OAuth@ietf.org>

    https://www.ietf.org/mailman/listinfo/oauth

    _______________________________________________
    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

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

Reply via email to