Re: [OAUTH-WG] Google's use of Implicit Grant Flow

Bill Burke <bburke@redhat.com> Thu, 16 February 2017 23:13 UTC

Return-Path: <bburke@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D4129485 for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2017 15:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AiHeonZz3skd for <oauth@ietfa.amsl.com>; Thu, 16 Feb 2017 15:13:40 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3583312944E for <oauth@ietf.org>; Thu, 16 Feb 2017 15:13:40 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECC077E9E0 for <oauth@ietf.org>; Thu, 16 Feb 2017 23:13:40 +0000 (UTC)
Received: from Williams-MacBook-Pro.local (vpn-234-21.phx2.redhat.com [10.3.234.21]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1GNDe8g024540 for <oauth@ietf.org>; Thu, 16 Feb 2017 18:13:40 -0500
To: oauth@ietf.org
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com>
From: Bill Burke <bburke@redhat.com>
Message-ID: <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
Date: Thu, 16 Feb 2017 18:13:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com>
Content-Type: multipart/alternative; boundary="------------3CBF49A545BE0997C6BB9517"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 16 Feb 2017 23:13:40 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/eoaTn4wj3-FwyvSpPNUxl0fkjhc>
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 16 Feb 2017 23:13:41 -0000

For our IDP [1], our javascript library uses the auth code flow, but 
requires a public client, redirect_uri validation, and also does CORS 
checks and processing.  We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a 
browser redirect

I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org




On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for 
> third-party JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
>
> Isn't this generally discouraged from a security POV? *Is there a 
> better OAuth 2 flow for third party SPA applications?*
>
> Aloha,
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth