[est31]

You mean HTTPS access tokens that are sent in the clear and accessible to any proxy server in the middle?

They are a good replacement of password based auth, and yes they are new. But that doesn't mean they are better than ssh keys.

Each time you authenticate to github you send that token in the clear (inside the TLS session, but there it's in the clear). This means that any proxy server on the way, anyone with access to github's infrastructure who gets to read logs of traffic, etc. can get a means to impersonate you. That's a major problem with this authentication protocol, and a step back from signature based ed25519 keys that ssh uses. There are HTTP auth schemes 10 times better than that (TLS-SRP, etc). I'm not saying that HTTPS access tokens were a bad addition, they are better than doing the same thing you do with these tokens but with passwords. But they are worse than ssh keys.

FTR you can also specify different users with ssh keys, by having custom hosts in ~/.ssh/config that point to different identity files.

[prepend]

Typically proxy servers don’t have access to the contents within an ssl session unless they are MITM the whole transaction. And at that point they could just MITM passwords and everything else sent through the session.

They are worse than ssh keys but I think are still acceptable as I don’t use any proxies that MITM my ssl sessions and I’d be able to detect if someone tried (assuming the root CA don’t go crazy and start allowing it).

[est31]

Depends on the type of proxy you are using, but yes, I should have pointed that out that many proxies do not access encrypted contents. Doesn't change the fact that such traffic is way more dangerous if the tokens are in the clear.

For ssh you also have multiple types of proxying, some which send your keys to the proxy server (very bad), others which base on encrypted tunnels and don't do that. HTTPS is I think similar to that.

> at that point they could just MITM passwords and everything else sent through the session.

For proxy servers you are right. but any read only vulnerability can be turned into a write vulnerability. e.g. that attacker who has read-only access to logs of github traffic can turn use that for an attack where they push commits, etc.

[prepend]

> Doesn't change the fact that such traffic is way more dangerous if the tokens are in the clear.

It’s very important as tokens are not in the clear, they are encrypted in the ssl session. They are not visible to anyone other than the client initiating the session and the server authenticate by the server cert.