IETF Logo Mail Archive

Re: [OAUTH-WG] Recommendations for browser-based apps

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Tue, 19 September 2017 21:47 UTC

Return-Path: <phil.hunt@oracle.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 2618A134343 for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 12Xea3kGAFRz for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:47:39 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 008751343AC for <oauth@ietf.org>; Tue, 19 Sep 2017 14:47:38 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8JLlZMv009701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Sep 2017 21:47:35 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8JLlYfo015882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Sep 2017 21:47:35 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8JLlYGE031043; Tue, 19 Sep 2017 21:47:34 GMT
Received: from [25.163.118.13] (/72.143.234.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Sep 2017 14:47:34 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CABRXCmwKDOSQQrDdCVBkDWSi85A7FL_R9d9sNzgdBTE_HyKDMw@mail.gmail.com>
Date: Tue, 19 Sep 2017 14:47:31 -0700
Cc: Stefan Büringer <sbueringer@gmail.com>, OAuth WG <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com>
References: <CAKAMr-Dws2RVRLv+xTa7j2zk+yhpCpYN-jUgxFos+j--Abv4uQ@mail.gmail.com> <CABRXCmwKDOSQQrDdCVBkDWSi85A7FL_R9d9sNzgdBTE_HyKDMw@mail.gmail.com>
To: Bill Burke <bburke@redhat.com>
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jpjRYbhwl_MlphI_KSYDybqIxMI>
Subject: Re: [OAUTH-WG] Recommendations for browser-based apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 19 Sep 2017 21:47:41 -0000

Except a refresh token is not purely bearer. The client is required to authenticate to use it. 

Phil

> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> wrote:
> 
> I'd be curious to the response to this too.
> 
> Seems to me that refresh token has the same possible security risks in
> an Angular app as an access token, except the refresh token is valid
> longer....Still, if you did the implicit flow, you'd have to have
> longer access token timeouts as it would be really annoying for the
> user to have to login again and again in a long session with your
> Angular app.
> 
> We have a javascript adapter that does Authz Code Flow with PKCE for
> our Angular app.  It also does CORS checks on the code to token XHR
> request just in case on the IDP side.
> 
>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <sbueringer@gmail.com> wrote:
>> Hi,
>> 
>> there were some discussions in January regarding recommendations for
>> browser-based apps
>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html).
>> 
>> I'd just like to ask if the Authorization Code Flow with PKCE is a valid
>> option for Single-Page-Applications (in our case Angular), because Implicit
>> Flow cannot be used in our scenario.
>> 
>> Authorization Code Flow with PKCE eliminates the necessity for client
>> secrets, but our concern is that exposing the refresh token to the SPA might
>> be a security risk, compared to the Implicit Flow were no refresh token is
>> exposed.
>> 
>> What's your take on this?
>> 
>> Kind regards,
>> Stefan Büringer
>> 
>> P.S. I couldn't find that much on the internet regarding Authorization Code
>> Flow with PKCE in SPAs, if you have some recommendations for good blog posts
>> I would be grateful.
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> 
> 
> -- 
> Bill Burke
> Red Hat
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email