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

[Neil Madden <[e-mail]>]

Hi Dave,

> On 25 Nov 2019, at 08:28, Dave Tonge <[e-mail]> wrote:
> 
> Hi Neil and Torsten
> 
> I agree that the risk is about token theft / leakage. My understanding is that we should assume that at some point access tokens will be leaked, e.g.Facebook: https://auth0.com/blog/facebook-access-token-data-breach-early-look/ <https://auth0.com/blog/facebook-access-token-data-breach-early-look/>
I think this example is interesting because DPoP (or mTLS) wouldn't have prevented it. The access tokens in this case were deliberately issued by Facebook to the wrong user to implement the "View As" feature, so PoP wouldn't prevent this as the tokens weren't stolen/leaked they were mis-issued and incorrectly scoped. (As I understand it the incorrect access token "had the permissions of the mobile app" - i.e. incorrect scope. It wasn't actually a token issued to the mobile app).

> If access tokens were cryptographically sender-constrained, then leaked/stolen access tokens would be useless.
> I take your point that some of the ways in which an access token would leak, would also leak the dPOP headers, this is why section 9.1 has the recommendations around `iat` and `jti`. While this doesn't eliminate the risk, it does reduce it.
> 
> So my perspective is that dPOP allows sender-constrained access tokens in scenarios where mutual tls / token binding is not possible. This is a good protection against token leakage / theft.

My perspective is that it's the claims that are doing the heavy lifting here. The signature is, by definition, valid for all RSes. Given that the claims (restrictions really) are the important bit there are simpler ways to achieve this - macaroons being my preference.

Some broader points about the uses and costs of PoP tokens:

In a backend microservice architecture, service to service calls are often authorized by service account tokens. These tokens often have significantly higher privileges compared to normal users because the same token is used for every request. So PoP-binding these tokens makes a lot of sense because compromise of one of these tokens has a large blast radius. It's also much easier to achieve PoP-bound tokens in a closed ecosystem - e.g., just spin up a service mesh with automatic mTLS between all service instances and bind your access tokens to those certs.

For some deployment models like IoT that have much riskier threat profiles, it can also make sense to do PoP because tokens might pass through various protocol-translating proxies and over riskier communication channels. In this case you're probably willing to accept a bit of extra complexity because you accept that as part of the cost of operating securely in these environments. (Or you don't and your internet-enabled lightbulbs become a botnet). But you almost certainly have power and resource budgets that you need to keep within, so amortizing the cost of any public key crypto over many requests is crucial.

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 - which is why I think any next-gen OAuth must support issuing multiple fine-grained access tokens. Where tokens can't be constrained at the point of issue, then the client should be able to constrain them afterwards at the point of use. They could do this via DPoP, but for all the reasons I've mentioned before I think macaroons make more sense here.

For mobile apps however, where the situation is much better than for SPAs, DPoP may have real value. A mobile app can realistically generate keys within a secure enclave that requires local user authentication to access (enforced by the hardware), and there's typically no risk of XSS. Mobile phones are at risk of attacks by physically present attackers (e.g., being left unlocked while you go for a bathroom break), so DPoP could add real value here by making it much harder to use those apps without the user's consent - against even quite determined and sophisticated attackers.

If there is support in the WG to move the draft forward, then I'm happy that I've made the points I wanted to make. I would still like to see a much expanded rationale section with a precise description of the threats intended to be protected against and the limitations of the approach. I'd also like to see consideration for allowing reuse of a DPoP proof token for several requests, to amortize the cost. And I'd like to see the ability for DPoP tokens to be scope-constrained and expiry-constrained (i.e., timeout set by the client) as additional optional ways to lock it down.

-- Neil