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

Bill Burke <bburke@redhat.com> Mon, 09 February 2015 20:06 UTC

Return-Path: <bburke@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7F1A87C6 for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 12:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.212
X-Spam-Level:
X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqvVesmSLeF7 for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 12:06:48 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB151A8842 for <oauth@ietf.org>; Mon, 9 Feb 2015 12:05:43 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t19K5hDI000554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <oauth@ietf.org>; Mon, 9 Feb 2015 15:05:43 -0500
Received: from [10.10.61.137] (vpn-61-137.rdu2.redhat.com [10.10.61.137]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t19K5gNw016724 for <oauth@ietf.org>; Mon, 9 Feb 2015 15:05:42 -0500
Message-ID: <54D91317.9010101@redhat.com>
Date: Mon, 09 Feb 2015 15:05:43 -0500
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com> <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com>
In-Reply-To: <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/19ybjkMSxyl9-KClwkZJEw1KwMI>
Subject: Re: [OAUTH-WG] Confusion on Implicit Grant flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2015 20:06:50 -0000

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.Lewis@motorolasolutions.com
> <mailto:Adam.Lewis@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