Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Tomek Stojecki <> Wed, 24 July 2019 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CAF112034A for <>; Wed, 24 Jul 2019 00:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7LPGu_Cd_QG7 for <>; Wed, 24 Jul 2019 00:50:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C94611200D6 for <>; Wed, 24 Jul 2019 00:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1563954612; bh=xZJExtcgu7zK55NoJVdIk0kmyV/x4mK9Wk5e2/uHASs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=EiMOL/20hOfFg9RLd60DHnjFIRxSJFdB6e/3vBAjT4ZZy0/kSp1zIwFvjBTqIFVqlKLfNYfsqGDHciHIpok4DV6RLMjfqseBXVLp+JZ3Es/r/9XXi8gMfMSAMuowSUmRX33JOCMNwLW1/l7O8FwDR1tfS6HmTkdlg22DhajWFcxFpptMzVFw16NcmiF1ZWHk3fD2FVBSanIaq80qrcbJlUjW1axlDPRfmmHmirkUNptiN2u4+uRWSwZvQZKg/iCIeNfnwG3XEvQMYC29rPsG20UPv37u76/zw6dcDvivwvSaVJJUth9EESYlN16qtCpYn+JOfGmfbAXXIWSHM16RdQ==
X-YMail-OSG: FX1z1pMVM1mjGZNX13aNVRyipu_pT3dW5PENpHJlFfQzufvSoRex_4_0bNPXxB1 zBR0hyo4kKO0g4xAWuPQU8WQyjhrYVa9QVH1hPYJsK_yuT658Ns3VYcS5QmBjjfIORGQyU.CO4bb fE7gJsv6P9GOTWcoW3i5rtkY4KUDUqkJC96zqJnd8pdBKUFj5CB5l_D3qN7KfMtpR6VLOdWoKT55 3sWF4kVIffP9vh4yBUMjB.JKHjVfBMblp9tbRTDg3J6cSBg6ad8q6vf5l2q_6PKV48axQDSYTGTi 1oKracDXsyL4fFB1_GB0ymuAQGFMhZJE61oC3lUjMgikQ6VpIpyUcFjyA5EAFB5OmXZYHKWKCVDQ Rhy_qOIbxADc7HWSqDwLTDfpXB2kI4FhPv9W2O1D0CoC7KY2ouVv3I39_oFAhHSl7cEh_x.j1DOM 7SGz2cHrQILBXDGRohlYYDu706.9cj.lVY4URtm4jEkwOqdax7mH5Q1za3Ad0FSncH09Xxaj8D8t LgNa3.e4bgHbOF8mA7xfEhl4ZUZrtwAG3aYhwgGB2_9r3StCDsQYK4ghERWbFIn5oRXbuQXtIVzC qPiEUcWdV4Y5C_qAIiC_BzxcO_X6FPecpbUrg4t9Q7SsK5dvglkpOBlm0SGI5hAUs5Jm1oSj73Bx n4nWY9uJB5GWJBkcisAOMyzcqIUw.RIkZ2mixUfUG9ooe3.7Rw4kkOhlXF7GWubkGBteQTv.iulL B8TynhLejBTh_dQjw5t1ujRBWJQrcFQeEVBo_PL3unxLjl0a60VI3UU.XZCNQK3GV_R8XlrJrum_ _FLzwGWxlTmu3O9DOD9i8K0Lav1TswnNL1whpX8Xrv6fllWqIwdE7ry1BCBanlf9H2Iiygg8SXM2 dmGxyDjMw2q0gyCPI6pHKcz3HeUZNXmV7MImlW_Uvn85gjbdE8ANvxuHhr6_EsVyHMP8JunMkVDh 4JRxcr.K7MUVPnOFUnjF0iDipgEJKY3bwtmTznK8cBR7h1qJj4X8X2ioi7QodNFN6F85KoBwXtSP B1LY5CVXXw5FKx8HyqvQ89AuFPHDX9_tnPnV.Eg_kxjfIJ0X5fz.ycDhIMFv99ZAC5ekPAXzczyz dYExo58Fs6wVQW5pgROoieu.DTTtHxz.LtdSbqkyKCunTC0ROhFFWLC6FFhj3yy_8ZFLZA.OsCKk 9KUdRvRSDPtaKQJ0MTUBmR1JhByTV7MpGRnWWdADSIRC3XBeiUPO2F4J1F9O9xAO5ILZRqjkPa5N nd4r4WP5WSHEs5H.C7R9w7mpebg0JYZfpWPY0GA_guj0-
Received: from by with HTTP; Wed, 24 Jul 2019 07:50:12 +0000
Date: Wed, 24 Jul 2019 07:50:10 +0000 (UTC)
From: Tomek Stojecki <>
To: Brian Campbell <>, David Waite <>
Cc: OAuth WG <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.13991 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
Archived-At: <>
Subject: Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02
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: Wed, 24 Jul 2019 07:50:15 -0000

I agree that 6.1 takes too broad of a swipe, but I'd say with same-site cookies and (sadly) without token-binding, the suggestion to use cookie based session following oauth/oidc auth is a good one and should be incorporated perhaps in 6.2?

Leo sums it up well here:
> We need to be clear on the distinction between browser based apps that hold the token(s) in the browser space, vs. those that don't.  I agree that with this "common domain" architecture, the tokens should not be held in the browser, but it doesn't follow that oauth should not be used at all.  

Finally and sorry if this is off-topic, why isn't this discussion taking place in github? Aaron has uploaded the document there. This medium, while good for some things, seems to have a lot of shortcomings for this sort of discussion and review. 


On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite <> wrote: 

> On Jul 23, 2019, at 12:47 PM, Brian Campbell <> wrote:
> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <> wrote:
>> 2) Regarding architectures: I think this BCP should focus on recommendations for securely implementing OAuth in the different potential architecture. I don’t think we should get into the business of recommending and assessing other solutions (e.g. section 6.1.). Just to give you an example: Section 6.1. states 
>> "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.”
>> Really? What experiences is this statement based on? In my experience, sharing the same domain == host name tells you nothing about the overall architecture of a certain deployment. There may be several reasons why OAuth could be good choice in such a scenario, e.g. security considerations (since your common domain is just a proxy server encapsulating a whole universe of systems) or even modularity as an architecture principle. 
>> I suggest to remove section c. and to rephrase the second paragraph of the abstract.
> I believe the experiences that the statement is based on are the predominant practice over the course of much of the history of the web of using a cookie to maintain an authenticated HTTP session in web applications. When the script of the browser-based application is served from a domain that can share cookies with the domain of the API, then cookies can still be used to authorize requests (even if those requests are API calls rather than full page HTTP request/response). And I do believe that's likely a better decision in a lot of such cases. 
> That authenticated HTTP session may be establish from a username/password form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID Connect flow. Or even SAML for that matter. But the the requests after that are authorized by the cookie. 
> I think there's a tendency to assume because SPA style apps make API calls, they simply must use OAuth. Because API implies OAuth in the minds of many (which is a sign of its success). But OAuth isn't necessarily the only thing that can be used for API authorization. Cookies work too. I think/hope that's what Section 6.1. is getting at - providing some potential guidance that OAuth might not necessarily be the right choice in those cases where a common domain allows for a cookie. Perhaps the text in that section could be phased in a different or better way, but I think its useful to have some mention of in this document. 
> Although taking out "and OpenID Connect" from the sentence quoted above might be more appropriate and alleviate some confusion. 

Perhaps it should be turned into a stated document assumption (that the reader has decided to use OAuth) rather than guidance later in the document (that OAuth may not be the best fit)

There is AFAIK no set of security considerations or best practices we can point to for “use some non-standardized system for acquiring and using cookies” or even “here’s a standard for acquiring and using cookies”. Omitting some of the moving pieces of OAuth might alleviate some security concerns, but also resurrect some other security issues. The most immediate example that comes to mind: using a HttpOnly cookie-as-token instead of an access token may mean that you can’t have injected scripts exfiltrate the token, but applying the access token was also a mitigation against browser CSRF for your APIs.

OAuth mailing list