Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt

Aaron Parecki <> Sun, 17 November 2019 03:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CBEF120091 for <>; Sat, 16 Nov 2019 19:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 95alg0YrSz8R for <>; Sat, 16 Nov 2019 19:37:41 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C8E3120046 for <>; Sat, 16 Nov 2019 19:37:41 -0800 (PST)
Received: by with SMTP id p6so12807431ilp.1 for <>; Sat, 16 Nov 2019 19:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FEAHXExOQq0BHf9vW5rX6WdZzrUWPD68/gr8nOinAF8=; b=toR9AUA46Fpi+P7W7zATmAfm6+5d+5XzVG+czJnvQLhzlDybZ0jC38c0ORexXYMPYM M1bzEUNutI1OaXkeT5PDT35P/PcCC7e0kWNDF3a80mhux0EVt+KoOt4sVy/W57q6EY3X 9kS093n1wr3jiNj7wvIz45LV9y8UDxqjv55ZyaAdAmV9IxTC4nPp1UpnG3elF0cJSDCZ pypVtLu2mc3Nf9sCmfaHbJATLgW92WgXjbB6UnQ5T7icPglVjZH3ks7c94IWrGMTSTiT F3+Pl9rpWJS6n2PeIPXz4zGyBPidmCZw/IhEwzNjCIeIGXfIOaAY3TvGWuukx/xEuEZL gsCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FEAHXExOQq0BHf9vW5rX6WdZzrUWPD68/gr8nOinAF8=; b=cOwaqoNSeC3ASh4DPzXHiq4Rnt3iGtWc6f+hQkrkS2Q3jfng7EpFjUPk0YpSK4+li8 kCNR2gIuBjNMVYmDv/u1DWbBZvuExuT4YPccIxwJbnnzhRT3O6wqMoEomViTcQ5OLPD4 huPL2toYuE/RNNGf2AdSdJFgh3aQ92ACYpOooIhxc26xpbTOHfVH2ENdvqxhWaaeQS/9 ElUbBekB+s+Yl3LeRJfZwr/tbXKytog8HeL4rdWsTyLM7dFyWr1lAAoOCa7iba5RVo0C amUSXUNDc/LWi0d3lqrW9omEkva5gMeIgXyVibxt0es8tKH2j2IlfATaBPw6k54dQ2DL 55rg==
X-Gm-Message-State: APjAAAWb6LTGEiZWIEOmZi/keb0cqAYz2hwlIsN16P7hUOMo7ncm7CeN WQFHglhCcP40Tbv4VNbE2MQMHcQWJ357/w==
X-Google-Smtp-Source: APXvYqyxKgMkyZ2RxOr1DTcM4IuJGiVNerxMk59p7P0Rk7AU61rTj9SrEMpDjTArBHqXrrLG3XUw6Q==
X-Received: by 2002:a92:1612:: with SMTP id r18mr8785184ill.60.1573961860317; Sat, 16 Nov 2019 19:37:40 -0800 (PST)
Received: from ( []) by with ESMTPSA id c73sm3119497ila.9.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Nov 2019 19:37:39 -0800 (PST)
Received: by with SMTP id k13so14846510ioa.9 for <>; Sat, 16 Nov 2019 19:37:39 -0800 (PST)
X-Received: by 2002:a5e:8601:: with SMTP id z1mr187701ioj.214.1573961859519; Sat, 16 Nov 2019 19:37:39 -0800 (PST)
MIME-Version: 1.0
References: <> <> <3495798.29O3mTMRrG@papegaaij>
In-Reply-To: <3495798.29O3mTMRrG@papegaaij>
From: Aaron Parecki <>
Date: Sun, 17 Nov 2019 11:37:28 +0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Emond Papegaaij <>
Cc: OAuth WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-03.txt
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: Sun, 17 Nov 2019 03:37:43 -0000

Hi Emond,

Sorry I missed this email before my last update to the draft. I wanted
to address some of the questions anyway though.

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

This section has been renamed to "6.1.  Browser-Based Apps that Can
Share Data with the Resource Server". In particular, this section is
meant to point out that in some cases you can use traditional cookie
mechanisms instead of OAuth access tokens. I wouldn't say HTTP-only
cookies make APIs "very vulnerable to CSRF attacks" though. The
SameSite cookie attribute will prevent CSRF attacks, and is easily
deployable in this case. I will rephrase this section to better
clarify this.

> 8. Refresh Tokens

Draft -04 rewrote the refresh token section to allow refresh tokens in
browser based apps as long as they follow the recommendations in the
Security BCP.

> Without the browser, there is no application.

There are starting to become cases where browser based applications
can actually run without the user being present at the device now,
such as all the work around progressive web apps and background sync.
In these cases it may make sense to let JavaScript apps use refresh
tokens to perform work without the user being present.

> Shouldn't this BCP give actual recommendations on how to manage this (preferably without full page redirections)

This is a valid point and I'll bring this up in the next meeting to
see if there are any ideas about how best to handle a recommendation.

> 9.7. Content-Security Policy
> I think it should explicitly state the policies that should NOT be allowed

I'll bring this up in the next meeting.

Thanks for the feedback!

Aaron Parecki
On Tue, Aug 6, 2019 at 8:20 PM Emond Papegaaij
<> wrote:
> Hi all,
> After my vacation I've finally found time read up on the new BCP draft for
> browser based apps. First of all, thanks for the great work on this spec. I
> think this is a very important area to work on, as browser based applications
> are getting more and more common. Here's my feedback:
> 6.1. Apps Served from a Common Domain as the Resource Server
> This section has seen quite some comments, but IMHO one important aspect has
> not been emphasized enough: using an HTTP-only cookie to secure an API can
> make it very vulnerable to CSRF attacks. This was already mentioned by David
> Waite, but has not seen any response. Storing the access token (or session id,
> or whatever it is called when stored in a cookie) in an HTTP-only cookie will
> make it hard to steal, but also hard to protect from misuse. Any page can
> embed links to your API, and the browser will simply send the cookie.
> 'Traditional', server based, web applications require special protection
> against these kinds of attacks, but RESTful APIs often don't have such
> protection. IMHO advising to use a cookie to secure your API is therefore a
> dangerous advice.
> 8. Refresh Tokens
> This section also has seen a lot of comments. Why all this focus on the
> refresh token? All the attack vectors apply to the access token as well. If
> tokens cannot be stored securely in a browser based application, the
> authorization server should not issue any token at all. Leaking a single valid
> access token is likely to be more than enough for an attacker to get all the
> information he/she needs, even if it is only valid for a couple of minutes.
> Also, when an attacker manages to get an access token once, it is likely he/
> she will succeed a second time (i.e. via an XSS attack). Placing these
> restrictions on refresh tokens, without addressing the access token seems
> senseless to me.
> I think this section should be about the lifetime of the authorization and
> detecting potential leaks of tokens. For a browser based application, I see no
> use at all for offline tokens. Without the browser, there is no application.
> Therefore the access should be scoped to the browser session, and this is IMHO
> best checked by the authorization server. At Topicus, we plan to implement
> this with short lived access tokens and performing re-authentication in a
> hidden iframe with prompt=none. The disadvantage of this is that is requires
> OIDC for the prompt parameter. In this setup we do not need refresh tokens,
> but other solutions may also apply. Shouldn't this BCP give actual
> recommendations on how to manage this (preferably without full page
> redirections, because those destroy the state of a SPA), rather than simply
> forbidding refresh tokens?
> 9.7. Content-Security Policy
> A very important measure to secure your browser based application is a strong
> CSP, but it is also very hard to do correctly. The current advise is a bit
> broad. I think it should explicitly state the policies that should NOT be
> allowed (inline scripting, eval). This was already mentioned by Dominick
> Baier. Also, it could benefit from a few examples (correct and wrong).
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
> _______________________________________________
> OAuth mailing list