[ptoomey3]

It’s not at all about the security of delivering credentials over https, but more about the the complexity of trying to defend against weak passwords/credential stuffing with an api. For example, it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices to an api.

[u801e]

> it’s more or less impossible to add a defense in depth flow like https://github.blog/changelog/2019-07-01-verified-devices to an api.

Except that email, as described in the blog you linked to, is not a secure means of communication. What would be secure is to use a client side TLS certificate as part of the authentication process. That is, your browser/device sends it as part of the TLS connection negotiation process and then you authenticate via the username and password (via HTTP basic auth).

They're already doing something like that whenever one pushes or fetches from a git repository hosted on Github through ssh key authentication. It wouldn't be much of a stretch for Github to allow an account holder to upload a CSR and then Github signs it and makes a certificate, which the account holder can then add to the browser's or OS's certificate store.

[ptoomey3]

The verified device flow isn’t meant to be as strong as 2FA, but is a very strong mitigation against mass credential stuffing attacks for all users.

In terms of client certs, see my response in https://news.ycombinator.com/item?id=22849985. I agree client certs would be great. However, it can be tricky to couple your app logic with transport based security. A good example of this...chrome/google introduced a crazy cool concept called “channel bound cookies” - http://www.browserauth.net/channel-bound-cookies, but it never gained any traction because of the complexity noted.