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

John Bradley <ve7jtb@ve7jtb.com> Mon, 09 February 2015 20:16 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 D76071A88B4 for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 12:16:13 -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 Ke8_GU1anQ3O for <oauth@ietfa.amsl.com>; Mon, 9 Feb 2015 12:16:11 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (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 DC3DE1A88A4 for <oauth@ietf.org>; Mon, 9 Feb 2015 12:16:10 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id c9so24958773qcz.7 for <oauth@ietf.org>; Mon, 09 Feb 2015 12:16:10 -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=Yow/nw2CXboch0GFd5i/K8mJV4jcSwloSElZfjgcvAI=; b=Yc/QtggV3RG9/BPrX78eXqsYMGqIvcJmHel1sVHCS9LA0iQGalr4ZGtMEl4vocg77H 4mnsb3xrfKude474j9nWmlKo3C9lTQAdOxSLjMX2df0cwzTOVXd0uKEjhDbJ9nW8CEip QZGb/s9WtZxMqd22JcAyMhSy6CTfU8wxShTjxpq3v5RNsK4b9YB3jXiD8XBRmr/Iu0tk 0ObO7l9xiutncXpEX5QOspDcNQTRuA1NaVMM561hFhfPLaF2nOT4dDPLVG/MUygaBLvE Wmvl6GIe1p7ZZuXQ3NXBpK4i/6OXCSzaEqdQO0yOt7X7w/gfz1Qm4J5ZlxeTff0yeKvm 7CMg==
X-Gm-Message-State: ALoCoQnBH8Z2e5tlkTXk9TbCVeXs672LRemje36wh5XWxHcmOYuvO96AjaihrHc+sHWfjdoqfXkF
X-Received: by 10.140.44.134 with SMTP id g6mr42237691qga.85.1423512969957; Mon, 09 Feb 2015 12:16:09 -0800 (PST)
Received: from [192.168.8.101] ([181.202.146.189]) by mx.google.com with ESMTPSA id f46sm12889603qgd.3.2015.02.09.12.16.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 12:16:09 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AF558BD8-2116-4972-9BE4-A43EBC36DF8F"; 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: <54D91317.9010101@redhat.com>
Date: Mon, 9 Feb 2015 17:16:04 -0300
Message-Id: <1E340378-2D34-4AC8-906C-415EF025068E@ve7jtb.com>
References: <BLUPR04MB6918C7701D0DB90B0FA6B0D95380@BLUPR04MB691.namprd04.prod.outlook.com> <CANSMLKFMUQsBfOo=i0ki8PF_8PjRf7W3t=PiPo7qnftN9gUyWg@mail.gmail.com> <54D91317.9010101@redhat.com>
To: Bill Burke <bburke@redhat.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/FqU11qFz9uS8x3FeLEv3hrDy2i8>
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 20:16:14 -0000

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