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

[Emond Papegaaij <[e-mail]>]

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