Hi Dave,
> On 25 Nov 2019, at 08:28, Dave Tonge <dave.to...@momentumft.co.uk> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
