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 tools on a remote machine (like say for vscode remote over ssh ). The browser redirect to localhost won’t work because the CLI tool isn’t on localhost.
Something akin to ssh agent-forwarding ("oauth-forwarding"?) is really needed.
And it needs to be integrated similarly well like support for jumphosts.
Haven't seen anything like this, I'll try to bring this up with the openssh folks.
Curl can connect over unix domain sockets and ssh can forward them, I feel this would be a decent way to forward authentication as access control rules would apply to the sockets.
My SSH usage has multiple servers (staging, dev, etc..) and multiple clients (laptop, desktop). Some of those connections are going through jumphosts.
Setting up SSH tunnel would be possible, but a major pain, as every source/dest combination will need to have its own port, and every signin should specify the port number.
Compared to the current system, which prints a URL in terminal which I just need to click, it would be a major usability regression.
Some login requires Identity and access management (IAM) with a web interface only, if such gateway exists, a CLI tool would have to give user a link to open oneself I guess?
"If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.
The thread we are in is talking specifically about using cli tools on a remote machine, so that’s why I mentioned it. If you have that you don’t need a hole in the firewall.
Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into.
That's the point of TFA - unphishable second factors and ways to make them phishable. I'm saying that using the clipboard would be a bad idea in this case.
