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

Emond Papegaaij <> Tue, 06 August 2019 12:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C49B112013E for <>; Tue, 6 Aug 2019 05:19:56 -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 ACRkhluZMehQ for <>; Tue, 6 Aug 2019 05:19:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6410120137 for <>; Tue, 6 Aug 2019 05:19:54 -0700 (PDT)
Received: by with SMTP id v15so82135314eds.9 for <>; Tue, 06 Aug 2019 05:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=mA5u0YoV7SmJU5DpIayePHYT2j9AoKtXzkSr6jztC4Q=; b=RuC3BQEfVyZRDN1/bwdG+7Hi1aiSSPKL6y/BxUjzWeozWrVJy6HdnYEnwGM49r+7oE s44/4uVLrbI6DchAjaG2l/Zr0RZdZ7QPyJz0hnc+xIKXGRF7OTClBu27FrWbsreZYArP JufGgOUO7jF/g2Q4+85PI6VnVASGQ6e4NvsT0hi6sMVd1IP25VEM8Tb07EeFQlMW07Du GHwVYaA/CUvNWKQ1XiDwAJu8NaKEMvFmkXHDSYPG23C2U+TmSxv+/O5TCQJKjOjuig3p 2Y/9XsA8Sb2NZRBLCYZpMJK5xdPb/vpp8PVNQD2cURgOWHo/VqjpH8bpbTD0mzCXBNDW h7gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mA5u0YoV7SmJU5DpIayePHYT2j9AoKtXzkSr6jztC4Q=; b=Ea2Y/Xh5jV3rFbF4a9n/Tn6s9NVQhuZCNXe3AeeN5hZQBJvPtb6tzlLoVq9SVxyq9b y8fvFImkmHmqIDjrrMW535VtQv0626cVXBUlnbh4IjLd15ztDtGz3wQ8Soz3SoeWKi57 9d2uUWB74RKyAiUdWbXo6Ass3AlSA/9ee+ia0eGvaieWVyNIbENgm27xRjXry6MCnLxk dDxrR95urZjAFpjrLxH1BIdMkBKHbFpHDvWSanDt9YMywbv2pV64Eka7phvLhwplbdfr /Qg7Ec2/O2cccN9H5HKoATukfjn23hqdam1mGUrO+QQ/H3DQkx6UOmF+m3eATR7MrlsC +2EA==
X-Gm-Message-State: APjAAAV3Xphn3V7AG0uLFsmG1A+VjqOqKHtzEPEMYmmkOnbmZ8f1NwXY LMniV4XSQwbLFMDmvtvEkH5MP1av2XU=
X-Google-Smtp-Source: APXvYqxJkIbsaG0gX5exM7yY1U7QqO2wdFKeeugnyE1i0Bo+V0MtGklhi8QxbUp+/hBOy3zC9/BZyg==
X-Received: by 2002:a17:906:580b:: with SMTP id m11mr2932243ejq.0.1565093992402; Tue, 06 Aug 2019 05:19:52 -0700 (PDT)
Received: from papegaaij.localnet ([]) by with ESMTPSA id h10sm20729538ede.93.2019. for <> (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 06 Aug 2019 05:19:51 -0700 (PDT)
From: Emond Papegaaij <>
Date: Tue, 06 Aug 2019 14:19:50 +0200
Message-ID: <3495798.29O3mTMRrG@papegaaij>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
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: Tue, 06 Aug 2019 12:19:57 -0000

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