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

Adam Lewis <adam.lewis@motorolasolutions.com> Tue, 19 September 2017 22:03 UTC

Return-Path: <adam.lewis@motorolasolutions.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 DAC49134390 for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 15:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8m8FBtnLCRsf for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 15:03:16 -0700 (PDT)
Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (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 75B86134343 for <oauth@ietf.org>; Tue, 19 Sep 2017 15:03:16 -0700 (PDT)
Received: from pps.filterd (m0074419.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8JM39dC017128 for <oauth@ietf.org>; Tue, 19 Sep 2017 17:03:13 -0500
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by mx0b-0019e102.pphosted.com with ESMTP id 2d37fqrnqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <oauth@ietf.org>; Tue, 19 Sep 2017 17:03:13 -0500
Received: by mail-oi0-f69.google.com with SMTP id f3so39103oia.4 for <oauth@ietf.org>; Tue, 19 Sep 2017 15:03:13 -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; bh=nN5UIwRbKJQWSiLYBWMRkxd+rOQ6EiM+NvMUa3wNeIc=; b=L4jGF3bwVImYE6crWD6qOj2pkgKVM+D/ZO8Ee4TG3nfX00DSNi3l9qfetDfOleBwTK cEDa7KZWLmSKyTwV+Ga6Bb9hSl3Z2HO2ChNHQ2LpZY6uTWZ7wnnJkfMBfX0gDwHZ5K/z H0aCHWRCVfYpWrcjALQuWHkDJN9iHPOULd65ks53ZOmNVymoqEyVdgReT7T1u0IinbwU grrRwzxz2pH763psFbzgfxavp4yVuOXY21cCEOiIV5FLhp6Q3N5pXin8xdcNRgOkmG9o Vof567Y+wKO/9pu2lel5pmwJIsQETanLBnaER2KoussctXZ2CzFwVkCmsbjpfnQ537ID uX/g==
X-Gm-Message-State: AHPjjUhyaPCQDkgYAXOnaSkS1a31h1f7XY3agHcMIzLdehju3R3IiSYm oxf5skeF87gx12HP4zedbxS0t4NiU745oHUeirMJ1jCDCViLpobo6ebKw5ZVhvFsitT5AQEcUdS zfjkYVPsEK9qDAw92cv6ZUw==
X-Received: by 10.202.71.151 with SMTP id u145mr3171984oia.222.1505858592697; Tue, 19 Sep 2017 15:03:12 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QALFAn0nipi93scpWDuuW/MWX/nNBes/VQwfqZN/lcQlQKnuN0G3yAMyXHRi9UlirHYTGMVTZH3RjemBfxUxds=
X-Received: by 10.202.71.151 with SMTP id u145mr3171967oia.222.1505858592405; Tue, 19 Sep 2017 15:03:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.32.139 with HTTP; Tue, 19 Sep 2017 15:02:51 -0700 (PDT)
In-Reply-To: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.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>
From: Adam Lewis <adam.lewis@motorolasolutions.com>
Date: Tue, 19 Sep 2017 17:02:51 -0500
Message-ID: <CAOahYUwYT-mFrdN-FvZArNCmVMn8G6X8504Z9EFY_rZ7A328qA@mail.gmail.com>
To: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
Cc: Bill Burke <bburke@redhat.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e51127bc6ac055992062e"
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709190301
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QP20FWr-_F_O7x_JaWWrE9eO98c>
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 22:03:19 -0000

Only for confidential clients.  No authentication is required for public
clients.

On Tue, Sep 19, 2017 at 4:47 PM, 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
>