When you generate a private key using openssl, it will prompt you for a passphrase.

I wonder if there are any solutions out there that can handle TLS client cert verification along with validating the username/password (which, if provided via HTTP basic auth, would be in the header of the request). That way, the application itself could just concern itself with serving resources, interacting with resources, etc instead of handling authentication or authorization.

The infrastructure edge device could communicate additional information if needed by adding headers to the original HTTP request when it's passed down to the endpoint that actually handles the request.

> 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.