Re: [OAUTH-WG] Feedback on OAuth for browser-based Apps
Dominick Baier <dbaier@leastprivilege.com> Tue, 23 July 2019 07:28 UTC
Return-Path: <dbaier@leastprivilege.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 DBC9312004C for <oauth@ietfa.amsl.com>; Tue, 23 Jul 2019 00:28:23 -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 P6IA8zKN3_yi for <oauth@ietfa.amsl.com>; Tue, 23 Jul 2019 00:28:22 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 A93D41200D6 for <oauth@ietf.org>; Tue, 23 Jul 2019 00:28:21 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id a15so40948523qtn.7 for <oauth@ietf.org>; Tue, 23 Jul 2019 00:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ofZeLA9X0xwQHASgLZJzP97tmG22PsUprRrzIdRgjEU=; b=JWHnb79sL7KsdrTGdOYCK3BKKO94j/XWD65hQ+txT+etTa6uLO+ULaEQIgw8TmCawu SKlIPHJxlxMj2VVzq52/9kmRirAWaeLRhD+yJqYp8+qlsffTDXnVD/tMKNoykG/EmRTF FkawAVjbWgkjVRd7AAr1NviWppShzaRSYUufdOKs5zKCP4noCAo/mH2E6Bci4jmdvsCG uHg+B09jR2kLAo/PJ2wuwQOodtUJkRXBUuyKzuFAEwCEIEasUj/Jk1lSE83Oapfpob5n fpBpguVO1A37gvoWG9ZRkpx7ke0gLnrf2sEvCBtzBJwfobaOZh0a8YNVY9QDeN3//QYP fNSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ofZeLA9X0xwQHASgLZJzP97tmG22PsUprRrzIdRgjEU=; b=WCR4SDCt3gbso9XrwpIPNyOrQSbM28ndDWKoaGw20f1s4N2NiVRSyx6HvmQzDytCwy JIsGBzJu7o2GebUziuYb5elQz3OMzjR0OLhLGEkLYvxXbenjoPaDY1yZnRCyU0IK20CF pr0s3+NQOkvT320v4SB+99BDcqLkPctMmf7daQ8dGCxfvoeg2SD3ETZ91UOe1WFQdzL1 FIBOerV76h75+4ndKDka6c7XS9Sk0yD7KPadGu1bXOS8PO1cMkvKHYzU0qNvQlEavq/i YVm9l6V6XAz3Jvx8766m8Bgj31jWJV1KpssvJI+X9BTBiL2pLaHOAFF83kTYrwXY6eeS UJuw==
X-Gm-Message-State: APjAAAWQ41B8gXHTSlcY6DwRHXKdtEVcnMohZozLTJcYD4kbQsf7JB2t /WywJpNECWwMbmlnIyGlBVjJTbpkqsf6e9YNzvaAy/4=
X-Google-Smtp-Source: APXvYqwgYFkjecL51UYjW/4VKhVqvi7EyYdGHdBgBBVh7s8p8TiSaHW5JZUBSmOgvOynOg0R1fD1aRCOzaCSIQ1ERS8=
X-Received: by 2002:aed:36c5:: with SMTP id f63mr53435654qtb.239.1563866900421; Tue, 23 Jul 2019 00:28:20 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jul 2019 00:28:19 -0700
From: Dominick Baier <dbaier@leastprivilege.com>
In-Reply-To: <CAO7Ng+tyHaKQgJ4PcrcEpMcteqvdH2PE1CQP5j+5DqKJWuKPoQ@mail.gmail.com>
References: <CAO7Ng+tyHaKQgJ4PcrcEpMcteqvdH2PE1CQP5j+5DqKJWuKPoQ@mail.gmail.com>
MIME-Version: 1.0
Date: Tue, 23 Jul 2019 00:28:19 -0700
Message-ID: <CAO7Ng+sLuLczQYjYX7yHSfVJd7bx5y0RnDofRh_Mb2Se+vA0=A@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001373b5058e54232f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/z4JXt5ljpARIUD2TO8w-_KX6dys>
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 <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, 23 Jul 2019 07:28:24 -0000
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’t state optional when PKCE is used? thanks ——— 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 “Application Architecture Patterns”. I definitely want to distinguish between applications only accessing same-site back-end services and “others”. Not sure if “dynamic application server" and “static application server” 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’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/aspnetcore21/BFF And a blog post https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/ 9.7 <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#section-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 <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02#ref-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! ——— Dominick
- [OAUTH-WG] Feedback on OAuth for browser-based Ap… Dominick Baier
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Dominick Baier
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Neil Madden
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Filip Skokan
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Dominick Baier
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Neil Madden
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Aaron Parecki
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Dominick Baier
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… David Waite
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Justin Richer
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Filip Skokan
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Justin Richer
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… Leo Tohill
- Re: [OAUTH-WG] Feedback on OAuth for browser-base… n-sakimura