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 422BD12018F for ; Tue, 23 Jul 2019 02:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.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 1YI2qANHq4LA for ; Tue, 23 Jul 2019 02:46:25 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 9D56F120194 for ; Tue, 23 Jul 2019 02:46:24 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id g17so42447242wrr.5 for ; Tue, 23 Jul 2019 02:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DHJYxCFuu3n9fe6kwRnnj9SigenkqykKJSEm+exJYlc=; b=dz5VvUtfj4JZ/oIXDBvGEFrnVMdtekRPRxaw2n7Wq1UguiwJos5ZyogB18O9o0nc7u GvnOAXbIyHZ7RP3R3sMzyPxqLoeLVxUdRJSCdWd9NQdCasAcuqyiM2lPV/aDX1zlAUrJ xPczr9SIf5sxNhBsaiQbVHLv30Qs3xh3fOUIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DHJYxCFuu3n9fe6kwRnnj9SigenkqykKJSEm+exJYlc=; b=OAxmAIqsMLa9sLojk6IXRaoG5LETwyiWBcP2sUBbmyDKF2HgZA839rWV4eKtqXTl/2 sFxPS8AUit7FDJIZbi7uq1yobQRA1P87STQ5G9RF+SwyHSvLFZYY5vyluvY1BEiJA+F7 yqgRYMdqcmltITMCQ1PnlFOWg8MIiNCvnkvKowY6SX1UPivrhJ3cia1GrVlPxh4DFpvJ 2+fG10oBoo4wLwE91qQupOpVLAWfbXuaardVHXc/IVwmkU/jINVapPB3FvjrHWkJkY1p haMIL/QawwUuyB9Yj5bXoe/ExLKAlS6CrRee5HoqhoycW8xmRyZP0DE1HyhByPxGvzk+ eIMw== X-Gm-Message-State: APjAAAU9SZyAZdJpIfkFuQCfbio4P5T01VGx2LI0zcPAs+qBRFIryMS2 l/AiWlOPoF9Kx1cn6BOxp17Oxg== X-Google-Smtp-Source: APXvYqyhhJbITIP3ui14/5FNTiQJ/pSYYMXO8roxpvVUKu0AbH4OUL5B2FV7VueCRNNOMhWQDTd1JA== X-Received: by 2002:a5d:4e06:: with SMTP id p6mr37689988wrt.336.1563875183007; Tue, 23 Jul 2019 02:46:23 -0700 (PDT) Received: from [192.168.2.140] (77-44-110-214.xdsl.murphx.net. [77.44.110.214]) by smtp.gmail.com with ESMTPSA id p14sm34459800wrx.17.2019.07.23.02.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 02:46:22 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 23 Jul 2019 10:46:19 +0100 In-Reply-To: Cc: Filip Skokan , OAuth WG To: Dominick Baier References: <7AB72379-075B-411D-B149-3759F16B001A@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 09:46:28 -0000 --Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not sure I follow - the current OAuth security topics BCP allows for = using either state or PKCE for detecting CSRF = (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4= .7.1 = ), with some caveats for when state is preferred. I think I prefer the current wording in the browser-based draft, which = provides a much clearer unambiguous recommendation. -- Neil > On 23 Jul 2019, at 09:31, Dominick Baier = wrote: >=20 > Yes it would. >=20 > =E2=80=94=E2=80=94=E2=80=94 > Dominick >=20 > On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com = ) wrote: >=20 >> Wouldn=E2=80=99t that contradict the security topics BCP? >>=20 >> Odesl=C3=A1no z iPhonu >>=20 >> 23. 7. 2019 v 9:44, Neil Madden >: >>=20 >>> Technically it could be optional, but it means that a CSRF attempt = will only be detected by the AS not by the client. If we consider the = possibility of a malicious AS, then this could allow Login CSRF attacks = against the client. The client would also have to be sure that the AS = actually implements PKCE. So I think it=E2=80=99s safer to leave the = recommendation as-is.=20 >>>=20 >>> On 23 Jul 2019, at 08:28, Dominick Baier > wrote: >>>=20 >>>> Forgot one more thing >>>>=20 >>>> In 7.1 >>>>=20 >>>> Browser-based apps MUST use the OAuth 2.0 "state" parameter to >>>> protect themselves against Cross-Site Request Forgery and >>>> authorization code swap attacks and MUST use a unique value for = each >>>> authorization request, and MUST verify the returned state in the >>>> authorization response matches the original state the app = created. >>>>=20 >>>> Isn=E2=80=99t state optional when PKCE is used? >>>>=20 >>>> thanks >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> Dominick >>>>=20 >>>> On 22. July 2019 at 08:14:33, Dominick Baier = (dbaier@leastprivilege.com ) wrote: >>>>=20 >>>>> Hey,=20 >>>>>=20 >>>>> Just read the spec - good to see the progress. Some feedback: >>>>>=20 >>>>> I am yet undecided if I like the categorisation of the = =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitely want = to distinguish between applications only accessing same-site back-end = services and =E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic = application server" and =E2=80=9Cstatic application server=E2=80=9D = should be handled differently - they are deployment details and should = not decide on the application security architecture. Also not sure how = realistic it is to deploy a typical applications solely from e.g. a CDN. = But I don=E2=80=99t have the right answer wrt to categories right now. >>>>>=20 >>>>> 6.1. Apps Served from a Common Domain as the Resource Server >>>>>=20 >>>>> > OAuth and OpenID Connect provide very little benefit in this >>>>> deployment scenario, so it is recommended to reconsider whether = you >>>>> need OAuth or OpenID Connect at all in this case. >>>>>=20 >>>>> I think you are mixing authentication and API access here. = Depending on application scenario it makes a lot of sense to use OIDC - = but rely on the resulting session to control API access.=20 >>>>> Unless you want to dive into the details here, I suggest you = remove the mention of OIDC because it is misleading. >>>>>=20 >>>>>=20 >>>>> 6.2. Apps Served from a Dynamic Application Server >>>>>=20 >>>>> I have a .NET sample for that=20 >>>>>=20 >>>>> = https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcor= e21/BFF = >>>>> And a blog post >>>>> = https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wi= th-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ = >>>>>=20 >>>>> 9.7 = . Content-Security Policy >>>>> A browser-based application that wishes to use either long-lived >>>>> refresh tokens or privileged scopes SHOULD restrict its = JavaScript >>>>> execution to a set of statically hosted scripts via a Content >>>>> Security Policy ([CSP2 = ]) or similar mechanism. >>>>>=20 >>>>>=20 >>>>> I would rather say that ANY JS app should use CSP to lock down the = browser features to a minimal attack surface. In addition, if refresh or = access tokens are involved - further settings like disabling inline = scripting (unsafe inline) and eval should be disabled. >>>>>=20 >>>>> Thanks for doing this work! >>>>>=20 >>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>> Dominick >>>> _______________________________________________ >>>> 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 = --Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Not = sure I follow - the current OAuth security topics BCP allows for using = either state or PKCE for detecting CSRF (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13= #section-4.7.1), with some caveats for when state is preferred.

I think I prefer the = current wording in the browser-based draft, which provides a much = clearer unambiguous recommendation.

-- Neil

On 23 Jul 2019, at 09:31, Dominick Baier <dbaier@leastprivilege.com> wrote:

Yes it would.

=E2=80=94=E2=80=94=E2=80=94
Dominick

On 23. July 2019 at 10:08:43, Filip Skokan (panva.ip@gmail.com) = wrote:

Wouldn=E2=80=99t that contradict the = security topics BCP?

Odesl=C3=A1no z iPhonu

23. 7. 2019 v 9:44, Neil Madden <neil.madden@forgerock.com>:

Technically it could be optional, but it means that a CSRF = attempt will only be detected by the AS not by the client. If we = consider the possibility of a malicious AS, then this could allow Login = CSRF attacks against the client. The client would also have to be sure = that the AS actually implements PKCE. So I think it=E2=80=99s safer to = leave the recommendation as-is. 
On 23 Jul 2019, at 08:28, Dominick Baier <dbaier@leastprivilege.com> wrote:

Forgot one more thing

In = 7.1

Browser-based apps = MUST use the OAuth 2.0 "state" parameter to
   protect themselves against Cross-Site = Request Forgery and
  =  authorization code swap attacks and MUST use a unique value for = each
  =  authorization request, and MUST verify the returned state in = the
  =  authorization response matches the original state the app = created.

Isn=E2=80=99t = state optional when PKCE is used?

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick

On = 22. July 2019 at 08:14:33, Dominick Baier (dbaier@leastprivilege.com) wrote:

Hey, 

Just read the spec - good = to see the progress. Some feedback:

I am yet undecided if I = like the categorisation of the =E2=80=9CApplication Architecture = Patterns=E2=80=9D. I definitely want to distinguish between applications = only accessing same-site back-end services and =E2=80=9Cothers=E2=80=9D. = Not sure if =E2=80=9Cdynamic application server" and =E2=80=9Cstatic = application server=E2=80=9D should be handled differently - they are = deployment details and should not decide on the application security = architecture. Also not sure how realistic it is to deploy a typical = applications solely from e.g. a CDN. But I don=E2=80=99t have the right = answer wrt to categories right now.

6.1.  Apps Served from a Common Domain as the Resource = Server

> OAuth and OpenID Connect provide very = little benefit in this
   deployment scenario, so it is = recommended to reconsider whether you
   need OAuth or OpenID = Connect at all in this case.

I think you are = mixing authentication and API access here. Depending on application = scenario it makes a lot of sense to use OIDC - but rely on the resulting = session to control API access. 
Unless you want to dive into the = details here, I suggest you remove the mention of OIDC because it is = misleading.


6.2.  Apps = Served from a Dynamic Application Server

I have a .NET sample = for that 

And a blog post
https://leastprivilege.com/2019/01/18/an-alternative-way-to-sec= ure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/

9.7. Content-Security Policy
A browser-based application that wishes to use either =
long-lived
   refresh tokens or privileged scopes SHOULD restrict its JavaScript
   execution to a set of statically hosted scripts via a Content
   Security Policy ([CSP2]) or similar mechanism.


I would rather say that ANY =
JS app should use CSP to lock down the browser features to a minimal =
attack surface. In addition, if refresh or access tokens are involved - =
further settings like disabling inline scripting (unsafe inline) and =
eval should be disabled.

Thanks for doing this work!

=E2=80=94=E2=80=94=E2=80=94
Dominick
_______________________________________________
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

=

--Apple-Mail=_0EBCC58E-0223-496B-8DF6-0C7C878526CB--