11–20 of 56 posts
I'm confused, isn't having the device listen on localhost necessary for the device authorization grant flow? What's the alternative (that, apparently, people are doing but shouldn't be)?
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…
The attacker may well be using a MacBook Pro, a real one. With a TPM.
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…
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…
Cross device webauthn is the better solution here but it's still vulnerable to the oauth phishing called out here.
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…
> For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). The attacker may well be using a MacBook Pro, a real one. With a TPM.
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…
This is what Intune and similar provide, but you need some existing, secure registry of devices before this works. Cross device webauthn is the better solution here but it's still vulnerable to the oauth phishing called out here.
> This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. I'm confused, isn't having the device listen on localhost necessary for the device authorization grant flow? What's the alternative (that, apparently, people are doing but shouldn't be)?
> This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. I'm confused, isn't having the device listen on localhost necessary for the device authorization grant flow? What's the alternative (that, apparently, people are doing but shouldn't be)?
My impression was that the device was repeatedly fetching site.com/auth/userid/session_id and waiting for a response with a token in it.
The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. Unfortunately this doesn’t work for CLI to…
I wonder if having the user copy-paste the token could work?