It would be great if OAuth could include some form of cryptographic attestation—similar to what is already present in WebAuthn—to ensure that only trusted devices can get authorization tokens.
In the case of CLI app authorization (where you are proving that the refresh + access tokens are being retrieved on the same device that issued the request), the CLI could generate a local key, store it in the TPM/keychain, and then in the browser you could prove that you have access to that same key.
For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something).
Of course, this depends on services choosing to implement such flows, and when you introduce a requirement for a TPM or similar, plus multiple cryptographic steps, implementors are likely to get lazy and just do something that works but is insecure (or they implement the flows badly with home-rolled crypto).
> It would be great if OAuth could include some form of cryptographic attestation
This is, as they say, a "known issue". Bearer tokens were defined in RFC 6750 and the thought was that more types of tokens would follow, including some that bound tokens and clients.
It took a while.
RFC 8705, mentioned elsewhere in thread, is one approach.
I guess this is what Heroku was pushing for [1] when client tokens were leaked. They wanted GitHub to adopt RFC 8075 [2], that combines mutual TLS auth with the tokens, so that the tokens can only be used by authorized clients, not just anyone that had possession of the tokens.
I think the only MacBook Pros with real TPMs were the 1, and 2, series from 2006/2007. Right now Apple don't allow you to do device identity attestation with the secure element. But in the world where you take this approach you don't just tie issuance to "I have a hardware keystore", you tie it to "This hardware keystore has an identity that I know belongs to a computer I own"
But the entire thread is about delegating the authentication, granting access to another machine or process. You want to give access to one device (e.g. TV) from the trusted one (e.g. iPhone).
Both devices might be very pricey, real, up-to-date machines with TPM and keys and everything you want. The problem is that you can't tell whether the TV is the one TV that the iPhone's owner means to sign in.
Yes, but the idea is that you'd enroll the device (and its TPM), and thence wouldn't be phishable like this. Granted, there might still be a problem at device enrollment time.
See sibling thread, we're being duplicated; the point of this OAuth flow is to sign in on a different device, using the trusted one. That different device might be a legitimate TV with a TPM and cryptographic attestations that it truly belong to John Doe, there is still no way for your iPhone and Apple to check whether you meant to sign in to John Doe's TV or if they are a scammer and sent you the (legitimate) sign-up link over email.
Okta actually supports this with their device identity policy, but in this scenario the IdP doesn't necessarily have insight into who's issuing the token (The AWS case involves AWS getting a valid auth from Okta and then issuing the token) so that wouldn't work. RFC 8705 covers binding tokens to an mTLS Identity but basically nobody supports that.
WebAuthn uses such a directory already. Most implementations validate the attestation against a public database of ‘trusted’ device types (and DAA enables this to be done without compromising anonymity, up to the uniqueness of a device type)
That's not a trust statement, and it's not reliable as a proof. You can reliably tell you've seen this authenticator before, but that doesn't solve the problem being described here
In the case of CLI app authorization (where you are proving that the refresh + access tokens are being retrieved on the same device that issued the request), the CLI could generate a local key, store it in the TPM/keychain, and then in the browser you could prove that you have access to that same key.
For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something).
Of course, this depends on services choosing to implement such flows, and when you introduce a requirement for a TPM or similar, plus multiple cryptographic steps, implementors are likely to get lazy and just do something that works but is insecure (or they implement the flows badly with home-rolled crypto).