| I also think client certificates is a better solution. However, it does not have to be single per-user. For example, a service that you register an account on can issue a certificate to you; you could use it directly or you could use that certificate to issue another certificate to yourself, with a different key, and storing the private key of the original certificate on a separate computer that is not connected to the internet, making it less likely to compromise (if the certificate actually used is compromised, it could be revoked and you can issue a new one to yourself). If the service defines an extension for the authorization granted by the certificate, then you could issue a certificate to yourself that has an extension to restrict the authorization, therefore allowing partial delegation of authorization. (Some operation would be authorized only if all of the certificates in the chain authorize that operation.) The partial delegation of authorization can also be used to issue certificates to others, perhaps for a limited time (by setting the expiry date). For example, if one service can access another service to do some operation on your behalf, you can issue a certificate to the first service (this is one case where a client issues a certificate to a server), with the limited authorization that is required, and then that first service will use that certificate to authenticate with the second service, to do the operation. A service that wants someone to be able to use their account from another service to log in to their own one can also do so (although usually this should not be required, since someone might not want the other service). The private keys can optionally be passworded for additional security, and the server doesn't know nor care about this. (Passworded private keys is probably not useful for server certificates, but it is useful for client certificates.) The use of mutual TLS authentication has other security benefit as well. |