Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

[Torsten Lodderstedt <[e-mail]>]

> On 25. Nov 2019, at 17:06, Aaron Parecki <[e-mail]> wrote:
> 
> 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.

It’s also softens the requirements since to would not require SPAs to have a PoP mechanism. 

I think that’s ok, since SPAs with all APIs and token handling in the browser will anyway not be the security critical ones. SPAs serving as frontend for security sensitive applications can cover API interactions in the backend (where we have practical measures available for sender constrained access tokens. 

> 
> Aaron
> 
> 
> 
> On Mon, Nov 25, 2019 at 6:08 AM Neil Madden <[e-mail]> wrote:
> On 25 Nov 2019, at 12:09, Torsten Lodderstedt <[e-mail]> wrote:
> > 
> > Hi Neil, 
> > 
> >> On 25. Nov 2019, at 12:38, Neil Madden <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>