Hi Neil, > On 25. Nov 2019, at 12:38, Neil Madden <neil.mad...@forgerock.com> wrote: > > But for web-based SPAs and so on, I'm not sure the cost/benefit trade off is > really that good. The biggest threat for tokens being stolen/misused is still > XSS, and DPoP does nothing to protect against that. It also doesn't protect > against many other ways that tokens leak in browsers - e.g. if a token leaks > in your browser history then the threat is that the attacker is physically > using your device, in which case they also have access to your DPoP keys. In > the cases like the Facebook breach, where highly automated mass compromise > was achieved, I think we're lacking evidence that PoP would help there either. > > The single most important thing we can do to protect web-based apps is to > encourage the principle of least privilege. Every access token should be as > tightly constrained as possible - in scope, in audience, and in expiry time. > Ideally at the point of being issued ...
I tend to agree with your assessment. The simplest way with current OAuth is use of code+pkce+refresh tokens, narrowly scoped access tokens, and resource indicators to mint RS-specific, privilege restricted, short lived access tokens. Do you think we should spell this out in the SPA BCP? best regards, Torsten.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
