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 8059012013F for ; Sun, 21 Jul 2019 23:14:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-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 5OuVbX2otUzh for ; Sun, 21 Jul 2019 23:14:37 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 8279812013C for ; Sun, 21 Jul 2019 23:14:35 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id t8so27776139qkt.1 for ; Sun, 21 Jul 2019 23:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=cookQ3nQI17uH2eyNeW09E1Dh48DqAomDRYwZzuVBBw=; b=uo0ObeCyfjXHeYYv7zl2oDrPIRAGTth8/dOnOxJxk6PsWvHkY6TGy0kS2yndhjZ8w1 xyQHRLqdKJe7XmvxPxx/3SDQp2vxlVCpasqw+DU2ATjE6U3d67sryjl9ysEnH/oxOkDy DPbLautl9diLalSK8wwqxZy2r1vVCCHMFY5i9UNylT1Afs9/mcnx3+eAHCbq3eYy5/xa jTWXNu08hf0V1n2/3DE68mkI28xQK6YIwY8oWCV5aYm8CAgucMtX8uWq3stBzZkLCa2I WGXBdAGtaRVUnfQdTfbZNHdOkhUit9zbSXNLiFnJMdHgfF+3IZZQe2SYzx9wM8ha0Ypl WhrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=cookQ3nQI17uH2eyNeW09E1Dh48DqAomDRYwZzuVBBw=; b=KqN8/jdxShGv74mlphQvm/3xtCHwH8phxhlzxjO5ytadufhvZaK648dcHMgghkVlEK B8vNhuIa0NciP9vkPuO6QEZKi45L32sSEi5gDBJ/G06VMwU7rLSZxC/2TC5b2TDJ8v3Y lYa3SnrrAe4D2j4ho8ZEYEjgUZhwOewl+Hcsh9CJz3nSGcgOzvYatU7howWqh2AELmO5 UySHOQ2xwwdd4xNNCxBP3zauP0286qOMIw1oP65/XCmI8uvxjC7OblA0SYmIv1wr2blJ DCzJM/V2AcHTJP76a/gl7/HlbeduVAiukvgDvADedweGTkpqVB7ir6D2KJA/6lG/Jauq 2myQ== X-Gm-Message-State: APjAAAW+4jcJG5sh+rgB+4tJ/t95jP5XeaYPqsnDpLGLUNH+wf/lMkTy nl1imHx0hsAh0XXx4Lsugvmhx3UR71KDl4W8LIf3M8c= X-Google-Smtp-Source: APXvYqz60+kyqLXOIr/+GYp94X196y5+hZ1kIKjoNNu++/OICRdsGWlJKpNfkdd5zejsgeQ+hZIwKdOyMVi45e+ysYc= X-Received: by 2002:a37:a6cf:: with SMTP id p198mr44143894qke.259.1563776074150; Sun, 21 Jul 2019 23:14:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jul 2019 23:14:33 -0700 From: Dominick Baier MIME-Version: 1.0 Date: Sun, 21 Jul 2019 23:14:33 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000688ac5058e3efd63" Archived-At: Subject: [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: Mon, 22 Jul 2019 06:14:40 -0000 --000000000000688ac5058e3efd63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 applicatio= n 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=99= t 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 https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore= 21/BFF And a blog post https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-wit= h-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 --000000000000688ac5058e3efd63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hey,= =C2=A0

<= /div>
Just read th= e spec - good to see the progress. Some feedback:

I am yet undecided if I like the categorisat= ion of the =E2=80=9CApplication Architecture Patterns=E2=80=9D. I definitel= y want to distinguish between applications only accessing same-site back-en= d services and =E2=80=9Cothers=E2=80=9D. Not sure if =E2=80=9Cdynamic appli= cation 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.=C2=A0 Apps Served from a Common Domain as the Resource Server

> OAuth = and OpenID Connect provide very little benefit in this
=C2=A0 =C2=A0deployment scenario, so it is recommended to recons= ider whether you
=C2=A0 =C2=A0need OAuth or = OpenID Connect at all in this case.

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


6.2.=C2=A0 Apps Served from a Dynamic Application Serve= r

I have= a .NET sample for that=C2=A0

https://github.com/leastprivilege/= AspNetCoreSecuritySamples/tree/aspnetcore21/BFF
And a blog post

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 rath= er 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 invo= lved - 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=
--000000000000688ac5058e3efd63--