> Finally, my last real concern (which is why I'm pushing back so much on code >flow), is that this implies refresh tokens in the browser. My sense is that >given the danger of this, the original OAuth2 RFC (via the implicit flow) was >designed to limit the client's ability to obtain new access tokens based on >the user's authentication session at the AS (via a cookie). Allowing refresh >tokens now means that a successful attacker has unfettered ability to do this >(beyond just an access token's lifetime). And yes, CSP is mentioned as a >mitigation to protect the refresh token, but it was already necessary to >protect the access token, so CSP is not the only mitigation. What's missing is >strong guidance for token servers to provide mechanisms to limit the lifetime >of refresh tokens for these high risk client scenarios. I have a suspicion >that many existing token servers do not have such features, and this would >imply more features mandated for the token servers (beyond PKCE for example).
And to expand upon this serious concern -- CSP only protects the current page from things like XSS. It does not protect every other page under your domain. IOW, your app using/storing refresh tokens (and access tokens) is trusting every other page on the domain to also be protected from XSS. At least an access token compromised this way has an expiration, whereas unbounded refresh tokens won't necessarily. This is why I am pushing for strong guidance around refresh token expirations, and this requires the token servers to implement and enforce this. So this sort of threat should possibly be used in the document to reinforce and motivate such guidance. -Brock
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
