Return-Path: 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 B794B1320DC for ; Tue, 19 Sep 2017 18:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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] 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 ZcP4YZoFZXHc for ; Tue, 19 Sep 2017 18:31:58 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 1D5161321AC for ; Tue, 19 Sep 2017 18:31:58 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id p5so821546pgn.7 for ; Tue, 19 Sep 2017 18:31:58 -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=sRN9VgI19d/moiEgqjIoVgMh1F6k+bS2t7JCZedAlew=; b=paRlqQJtMV2E/6/cdfC7L4GoptL+KUqqs3orWTvkRLdGpNhzyY9q458PCykYxrRWN2 fJ6mct3nnx3iW6STLtZhSo0YaZeM/TKv5WqTmWTpR+MmO2ZKzOaJmIKsFGFFhPYHUxVz b0JZTnSUK7vtEKwrv+oc3aYrv5AEu98mtG16A/8wBdRZS9i7LwDpsCxLGG2s1kE5ym0F eY3c6FfIJd8/CXN45tbMhv5f1XWSytF8mRGVzO0qOutAWYgOm/gLyOJ827M13uGNH+KQ hHpi7zDCkVpkyrYrWUV+K7BFdeXOrzNSrLuQF00YJ0Z0IegurM0dPjKnCDS5JEJtnc/r EPUQ== 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=sRN9VgI19d/moiEgqjIoVgMh1F6k+bS2t7JCZedAlew=; b=K5N2FUdFVTkaXefrhqThMsHkyUwy12vsgEGHz8qCaTMnUB4tlCmYf5X8tY+nV13iBQ idcqqNgFePejnHI46je4lNRVhWpYTYEQvYYJXRepnyPTMHuQJSJxcIbJXUQsXEbz8F2f PNzArmS0lmzKH8vUslYeki2QeA5ZgiqQyXCOyG0+GGyU0TINX8DosUoam3m8pjtovy8g TAhOT0C06/Vvp0BfMNjfA+0gnxe4S1esADN1PQl6qycHNhZx1EPUitiUxrAGgUu8rf+x ap/9HZvcswNG3Jc4bzCWcjvykSc1yVA1wD0czefdSDPOAPgEI/F95zoVQ06BXEJzwcWk wsxQ== X-Gm-Message-State: AHPjjUg0Yovb8Z748gRXnxKcOzrhd4QMbtKbvR3gB1I0DKsIMHsg4L9y HohA6Iv3ZVGt/UwdvWrN5ZgX8o8/Kdc= X-Google-Smtp-Source: AOwi7QD6dIYC515eEUO07kyCuncktPgZKI4FhnF6k5igOuy0VhzJL2m4LJy+nhlBwcShSeK/1RntQg== X-Received: by 10.98.178.133 with SMTP id z5mr499154pfl.312.1505871117156; Tue, 19 Sep 2017 18:31:57 -0700 (PDT) Received: from [10.3.48.101] (mobile-166-170-38-115.mycingular.net. [166.170.38.115]) by smtp.gmail.com with ESMTPSA id n10sm5883209pfh.121.2017.09.19.18.31.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 18:31:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Mime-Version: 1.0 (1.0) From: Jim Manico X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Wed, 20 Sep 2017 09:31:48 +0800 Cc: nov matake , OAuth WG Content-Transfer-Encoding: 7bit Message-Id: <1A823C26-FC05-48C1-A2E1-7B2B6A2607BB@manicode.com> References: <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> To: Bill Burke Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:32:02 -0000 --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not always, Bill. There is a new standard called "same site cookies" or "fir= st party cookies" that allows you to programmatically remove this risk in so= me modern browsers, it's worth reviewing.=20 https://tools.ietf.org/html/draft-west-first-party-cookies-07 It's live in Chrome and Opera and will only grow in support. http://caniuse.= com/#search=3Dsamesite Jim > On Sep 20, 2017, at 8:44 AM, Bill Burke wrote: >=20 > Cookies are vulnerable to CXRF. >=20 >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake wrote: >> Why not using http-only cookies instead of refresh tokens? >> If the app can interact with AuthZ server through a hidden iframe with >> prompt=3Dnone param, you shouldn=E2=80=99t need refresh tokens. >>=20 >> If your SAP is running on a different domain with the backend server, >> Safari=E2=80=99s Intelligent Tracking Prevention will break the hidden if= rame way >> though. >>=20 >> On Sep 20, 2017, at 7:32, John Bradley wrote: >>=20 >> Right, Refresh token is bearer for native apps, that is why we came up w= ith >> PKCE to protect code. >>=20 >> For Angular the code flow with PKCE is probably better than the token >> response type. >>=20 >> However with bearer tokens it is still riskier than code with a confident= ial >> client so the AS should take that into account and not allow refresh toke= ns >> to live forever. >>=20 >> One future way to protect refresh tokens and perhaps Access tokens is to u= se >> token binding to bind the tokens to the user agent. You could do that n= ow >> for refresh tokens in Edge (Chrome has TB off by default still). >>=20 >> I think more work needs to be done to come up with a best practice for SP= A. >>=20 >> John B. >>=20 >> On Sep 19, 2017, at 7:02 PM, Adam Lewis >> wrote: >>=20 >> Only for confidential clients. No authentication is required for public >> clients. >>=20 >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) >> wrote: >>>=20 >>> Except a refresh token is not purely bearer. The client is required to >>> authenticate to use it. >>>=20 >>> Phil >>>=20 >>>> On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >>>>=20 >>>> I'd be curious to the response to this too. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan B=C3=BCringer >>>>> wrote: >>>>> Hi, >>>>>=20 >>>>> there were some discussions in January regarding recommendations for >>>>> browser-based apps >>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 toke= n >>>>> is >>>>> exposed. >>>>>=20 >>>>> What's your take on this? >>>>>=20 >>>>> Kind regards, >>>>> Stefan B=C3=BCringer >>>>>=20 >>>>> 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. >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Bill Burke >>>> Red Hat >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 > --=20 > Bill Burke > Red Hat >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not always, Bill. There is a new stand= ard called "same site cookies" or "first party cookies" that allows you to p= rogrammatically remove this risk in some modern browsers, it's worth reviewi= ng. 


It's live in Chrome and Opera and will only gr= ow in support. http:/= /caniuse.com/#search=3Dsamesite

Jim
<= br>

On Sep 20, 2017, at 8:44 AM, Bill Bu= rke <bburke@redhat.com> wrote= :

Cookies are vulnerable t= o CXRF.

On Tue, Sep 19, 2017 at 7:48 PM, no= v matake <matake@gmail.com> wr= ote:
Why not using http-only cooki= es instead of refresh tokens?
If the app can interact with AuthZ server through a hidden iframe w= ith
prompt=3Dnone par= am, you shouldn=E2=80=99t need refresh tokens.

= If your SAP is running on a different domain with the backend server,<= /span>
Safari=E2=80=99s Inte= lligent Tracking Prevention will break the hidden iframe way
though.

On Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> wrote:

Right,  Refresh token is bearer for native apps, that is why we came= up with
PKCE to prot= ect code.

=
For Angular the code flow with P= KCE is probably better than the token
response type.

However w= ith bearer tokens it is still riskier than code with a confidential
client so the AS should take t= hat into account and not allow refresh tokens
to live forever.

One future way to protect refresh tokens and perhaps Access tokens is to us= e
token binding to bi= nd the tokens to the user agent.   You could do that now
for refresh tokens in Edge (Ch= rome has TB off by default still).

I think= more work needs to be done to come up with a best practice for SPA.<= br>

John B.

On Sep 1= 9, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com>
=
wrote:

On= ly for confidential clients.  No authentication is required for public<= /span>
clients.

On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <= phil.hunt@oracle.com><= br>
wrote:

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

Phil

On Sep 1= 9, 2017, at 2:33 PM, Bill Burke <bbu= rke@redhat.com> wrote:

I'd be c= urious to the response to this too.

S= eems to me that refresh token has the same possible security risks in=
an Angular app as an acce= ss token, except the refresh token is valid
longer....Still, if you did the implicit flow, you'= d have to have
longe= r access token timeouts as it would be really annoying for the
user to have to login again and a= gain in a long session with your
Angular app.
<= blockquote type=3D"cite">

We have a j= avascript adapter that does Authz Code Flow with PKCE for
our Angular app.  It also does C= ORS 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=C3=BCringer <sbueringer= @gmail.com>
wrote:
Hi,<= br>

=
there were some discussions in January reg= arding recommendations for
=
browser-based apps
=
(https://www.ietf.org/mail-archive/web/oauth/current/msg16874.ht= ml).

I'd just like to ask if th= e Authorization Code Flow with PKCE is a
valid
option for Single-Page-Applications (in our case Angular), becaus= e
Implicit
Flow cannot be used in our= scenario.
<= blockquote type=3D"cite">
Authorization Code Flow w= ith PKCE eliminates the necessity for client
secrets, bu= t our concern is that exposing the refresh token to the SPA
might
be a security risk, compared to the Implicit Fl= ow were no refresh token
is
exposed.=

What's your take on this?

<= blockquote type=3D"cite">
Kind regards,
Stefan B=C3= =BCringer

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 go= od blog
posts
I would be grateful.

_____________________________________= __________
<= blockquote type=3D"cite">OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/li= stinfo/oauth

=



--
Bill Burke
Red Hat

= _______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/list= info/oauth

____________= ___________________________________
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


_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/l= istinfo/oauth



_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth




= --
Bill Burke
Red Hat

_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-3FF7B216-0132-4FF0-B3F0-1EC887A08862--