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

John Bradley <ve7jtb@ve7jtb.com> Mon, 09 February 2015 22:04 UTC

Return-Path: <ve7jtb@ve7jtb.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 8AE441A895C for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 14:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 0nNzlix40NrR for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 14:03:57 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA661A883B for <oauth@ietf.org>; Mon, 9 Feb 2015 14:03:57 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id k15so3102870qaq.12 for <oauth@ietf.org>; Mon, 09 Feb 2015 14:03:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XKUkF4VBn7IKsA+BToKU2N0+vPSpiHEGWTKsfYL8xFI=; b=Q9vyIFM2tQSH/PxvvWLdHL8hD3DwKP+lmsyc7t8j16/mjvpkHJy2aZWjqlWba6EoAz mNCNbchBlMUCOrpU+I+Df4OQQmKg2SU75SKNCKm4cyAhZ+aV44b0yvApT6+zurwq9nv4 OwFLzlXpy5SNcVcHGLlZjftAVuENc77F5XSr3XmGomaYC06uqWPqxxl3gEjUvKKq0sTH kgUsBkuoDpaOv0mjP9bPFTWwJzptKY7DSs4PnVvnY8heEahzK8aa2AKdRyo32dx8RvRz 8XOl+937Uys6vW6PxuGAKMdOlxy2H8vhN4gNkzgqb8JEnQNiptS96QKV+wRAP3DBSU1F 9A1A==
X-Gm-Message-State: ALoCoQn/vWqxqiMK8HLWC8KtgeLsHObX5MwZ+OLlE6M4qKiE/sRED58QZAEClZ/ENg4dxWqulz9o
X-Received: by 10.140.44.134 with SMTP id g6mr43184669qga.85.1423519436552; Mon, 09 Feb 2015 14:03:56 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id t10sm13154747qaj.23.2015.02.09.14.03.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 14:03:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5CF0AAD6-9D92-4FC9-9B7E-7DFDF77BC112"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54D92A3C.4060106@redhat.com>
Date: Mon, 9 Feb 2015 19:03:49 -0300
Message-Id: <32B26B45-FB75-47DF-8E34-42943B13F0E0@ve7jtb.com>
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com> <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com> <54D91317.9010101@redhat.com> <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com> <54D91D87.8040303@redhat.com> <FD337176-C292-4688-9CFA-A3C7DF40FCA2@ve7jtb.com> <54D92A3C.4060106@redhat.com>
To: Bill Burke <bburke@redhat.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/zMlUlI6s2CrCBJX4NLHThdYoLZg>
Cc: oauth@ietf.org
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 22:04:00 -0000

OK, I don't know if the WG has discussed the issue of fragments in browser history.  

So you are trading off several round trips against the possibility of a token leaking in browser history or bookmark?

One extension that Connect introduced was a "code id_token" response type that is fragment encoded.  That would let you pass the code directly to the JS saving two legs. 

On the wire with a registered https redirect implicit has less hops to protect, but you are correct that in the browser there might be threats that could extract the AT from the fragment if it is logged in the browser.

The real answer will eventually be using token binding to lock AT to browser instances.   

John B.
> On Feb 9, 2015, at 6:44 PM, Bill Burke <bburke@redhat.com> wrote:
> 
> For implicit flow, wouldn't the token be available in the browser history and could also possibly be bookmarked by accident or on purpose?  If a code is bookmarked, so what?  It is only valid for a tiny window (milliseconds).
> 
> Please tell me how a code is more likely to be leaked without a client secret when it can only be sent via SSL to a validated URL.
> 
> 
> On 2/9/2015 4:02 PM, John Bradley wrote:
>> 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 <bburke@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 <bburke@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.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
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com