I agree, the Facebook issue had nothing to do with extracting access tokens via a hack, it was entirely facebook’s fault for issuing access tokens improperly in the first place. They posted some amazing details on what happened on their website.
https://about.fb.com/news/2018/09/security-update/ If they couldn’t even get this right, it’s unlikely a sender constrained token would have helped here, and may have been bypassed just like the other three issues that led to the breach. > 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? I agree that this is probably the best advice we can give. Ultimately people will still make mistakes like the ones that led to the Facebook issue, so all we can do is point people in the right direction. Aaron On Mon, Nov 25, 2019 at 6:08 AM Neil Madden <neil.mad...@forgerock.com> wrote: > On 25 Nov 2019, at 12:09, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > > > 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? > > I think that would certainly be a great start. > > -- Neil > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
