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

Bill Burke <bburke@redhat.com> Tue, 19 September 2017 21:33 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 54D6F1343AC for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 GMoBoYXd0xdt for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 14:33:54 -0700 (PDT)
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) (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 495FD134390 for <oauth@ietf.org>; Tue, 19 Sep 2017 14:33:54 -0700 (PDT)
Received: by mail-vk0-f47.google.com with SMTP id p204so501489vkp.7 for <oauth@ietf.org>; Tue, 19 Sep 2017 14:33:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZPn6JjSBh6erjdaHE/dx61RXDfsapCZ+cjE0WYUh73k=; b=UrFEkFRI/LDGyRcugNDixGiTPIKQvAVgD81kyY7KS2zJ1D0HchnP0EThCEO2rijwMW ucIoNdOMgi8/aaMMnq8b+BDoKp5UcBcFrW6FiI4kxOGABebM5CSP7jqgsXrsQWKmZs7+ dVCWnhxxT1IN++sp1r6+tipjCKLFFW4UBU/0c2kCKqOU7mRAeCpDQWNy0Vbv6wNCi9Hq /v0GG7KW6LhGciwMk+00gf5KykrjwkMSbkLEJaprLag5KgnhdVyWVXe20/4mHBi2HXXg A9r6JTGV0bS9CtJd/jO9JH6bxONANtWOaMsWt/2JgQYGScGbrockCBfoeFjMKc9gigR2 noqg==
X-Gm-Message-State: AHPjjUieo6LVU2eqchb/2Du+7va0er0V39QWYfsy9jUp4dTTpcDoH1XZ j1MPGKL8Q7rZeBJCbAiScaGdlLStUFzmGKm1Y2R/Rg==
X-Google-Smtp-Source: AOwi7QA8fm5xucAvgVy3HxvYeYH1hyB/26z9JTDqpl2tzYCwDedeiTCGlu/mIDZv0EIf+7kVMUuBfkGLTXJEaNbq6tw=
X-Received: by 10.31.192.70 with SMTP id q67mr2201949vkf.28.1505856832986; Tue, 19 Sep 2017 14:33:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.55.79 with HTTP; Tue, 19 Sep 2017 14:33:52 -0700 (PDT)
In-Reply-To: <CAKAMr-Dws2RVRLv+xTa7j2zk+yhpCpYN-jUgxFos+j--Abv4uQ@mail.gmail.com>
References: <CAKAMr-Dws2RVRLv+xTa7j2zk+yhpCpYN-jUgxFos+j--Abv4uQ@mail.gmail.com>
From: Bill Burke <bburke@redhat.com>
Date: Tue, 19 Sep 2017 17:33:52 -0400
Message-ID: <CABRXCmwKDOSQQrDdCVBkDWSi85A7FL_R9d9sNzgdBTE_HyKDMw@mail.gmail.com>
To: Stefan Büringer <sbueringer@gmail.com>
Cc: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_5fswfcVM5CkPvptiutNdzTXaQo>
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:33:56 -0000

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