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

Jim Manico <jim@manicode.com> Tue, 19 September 2017 21:54 UTC

Return-Path: <jim@manicode.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 96A24132D42 for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
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 Lj3SRwPXsCC4 for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:54:51 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 70B04132397 for <oauth@ietf.org>; Tue, 19 Sep 2017 14:54:51 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id i195so554540pgd.9 for <oauth@ietf.org>; Tue, 19 Sep 2017 14:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjai3S0GJSBKIwpf2b/XeHeowGiTZCvuXUF3krc3Ir0=; b=AHTzqzmOgnb8VaArr8H9hzmlnrcEf13HJTQeP5JX0u+qCMszk7qB7j9X2TFgatRzZa ox3pVXfBX1KdVoSbAJ3NhWI0CjU7fIc/wiDqonGsV4TgFyEGwQK0c8+6mlmhkNGIzgcN 9DvRFv5ZRd9YNoqG7dfFQOSrnJWGccMOW1W2o5FklFZ99Koe3h1VBWlLWQExrcCphD8J /aLjbh8y3Kl3RSCa9UEihdtW7T3UbMipscEbCWJtpCbyXC0SHtZi5pbbLgcDy4qEHfXi ZpsxgK1XvJ6Ih6b+g3QoABgA56RI1ATAobwf/vMRI1/OW/nc+v/R2o6/iV9/wyxfawzi JoCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yjai3S0GJSBKIwpf2b/XeHeowGiTZCvuXUF3krc3Ir0=; b=ngfYdlChXf/te3FUEkuD2u1kAPehaa5ZclbC+rj2AwApHswWVb1cFKV8m3ZNzlEuPq mqrtMup7PBzEPnXZIsRQ8v0ozWPnauwchD4RAwImBwhYH/GJ6CgpiBxK7NOdmeNkPLDn 4H4tGk8znTC/ojrp1Y2+TIpru2TFAGrANPkAd7jugpQmbti3pY1tW4BH8CGYKx7/n2vv tGqQGQYiWXSKfFik4Dn4zeSQJtmDl2VMkLcnbCPIbbP/IGTO6ZIqDiPjUCINR+f+7Rg8 5suZBXIa32sTAhbEse2xPN/6FiOFPDwm7QLXrbgKt2l6AyU6fnZ8BWqI0fy1d2CxWxUp LILw==
X-Gm-Message-State: AHPjjUjAqKXwNeMz5feCGCJf+4kEQ9ViAY4sLF7t/K+5nNuqdG5uiVbg jJAAn9AL27mV0X4vCYSVN1pbgw6I2IU=
X-Google-Smtp-Source: AOwi7QCiejuVNzMzM45ZdI5kQXZ3MWIWZXyzR/OSjq8a9MUJiIGe8FgJNKv4H9gin2qN46hwKIp5Kw==
X-Received: by 10.99.127.4 with SMTP id a4mr52958pgd.124.1505858090566; Tue, 19 Sep 2017 14:54:50 -0700 (PDT)
Received: from [10.73.197.170] (mobile-166-170-39-127.mycingular.net. [166.170.39.127]) by smtp.gmail.com with ESMTPSA id g16sm5817593pfd.6.2017.09.19.14.54.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 14:54:49 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-585688D5-A18B-41D2-8F49-5EC8D6874AE7"
Mime-Version: 1.0 (1.0)
From: Jim Manico <jim@manicode.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com>
Date: Wed, 20 Sep 2017 05:54:45 +0800
Cc: Bill Burke <bburke@redhat.com>, OAuth WG <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <89A32B3A-849D-471C-9700-85815DC1C58D@manicode.com>
References: <CAKAMr-Dws2RVRLv+xTa7j2zk+yhpCpYN-jUgxFos+j--Abv4uQ@mail.gmail.com> <CABRXCmwKDOSQQrDdCVBkDWSi85A7FL_R9d9sNzgdBTE_HyKDMw@mail.gmail.com> <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bv_KifGqkcJ1znOyfbV5sEkpIx0>
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:54:53 -0000

One of the reasons I see so many security folk discouraging implicit in web applications (like your Angular scenario) is because even though refresh tokens and similar require authentication, how do you store that info securely in a browser? One XSS and it's http://m.youtube.com/watch?v=dsx2vdn7gpY

- Jim

> On Sep 20, 2017, at 5:47 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
> 
> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth