What about HTTPS client certificate?
https://techcommunity.microsoft.com/t5/iis-support-blog/clie...
I don't know enough about this to know if it meets your need but I've used them to authenticate to servers in college.
https://techcommunity.microsoft.com/t5/iis-support-blog/clie...
I don't know enough about this to know if it meets your need but I've used them to authenticate to servers in college.
The moment you have a certificate loaded into your browser, every single tracker will see the availability of client side certificates as a means to do fingerprinting. Either you configure your browser to expose your identity to every website who asks, or you get popups for every other website asking you to pick a certificate.
Web browser could probably fix this, but client certificates are uncommon enough that I doubt they care anymore. Like HTTP basic auth (and its lack of password manager integration), it seems like this feature only remains for compatibility reasons.
Like usual, middleboxes also tend to fuck up client certificate based authentication because they can't effectively MitM those connections (they don't have the key material you're using, and while they can try to fake a website's TLS certificate in intranets, they can't fake your credentials to remote servers).
It's real unfortunate. They're still used, though; some Kubernetes networking tools automatically provision client certs to authenticate API clients within the cluster (as well as protect the traffic from snooping).
I use client certificates since they are required in my line of business and had the impression that they are only presented when asked for by the website, only I explicitly allow it.
Other than the sites that I know require them, I have never been asked to choose a certificate when browsing random websites (windows 11).
Maybe the situation changed, or ad blockers have become better in the mean time, but last time I used them in Firefox, I was bombarded by client certificate requests browsing around the web.
The problem I have with the UX is that the certificate selection screen is a modal dialog that any URL seems to be able to bring up, and I found this abused in the wild. This, combined what made with the countless requests, made me move away from using them.
Another issue I struggled with was that every now and then I'd pick the wrong certificate and I couldn't for the life of me figure out how to correct this without restarting my browser and losing all my work. Switching between accounts for cert based auth was plain impossible.
Lastly there was the entirely unhelpful error state you can end up with when using client certs. Vague HTTPS errors that come down to "oh no something went wrong try reloading I guess" and weird side effect when certificates expired (from browsers sending old certificates to servers accepting expired certificates). The errors occur in the TLS layer, so you end up with authentication errors thst seemingly end up being handled as connection issues.
If you say these issues have been resolved, I should probably give mTLS another go.
The UI can be clunky, especially if you set up the certificates to be stored in TPM, since then windows sometimes pops up the dialog in a way that’s easy to miss. Other than that Ive no complaints. Good luck!
However, macOS has its own framework for doing https calls, which most macOS applications use. It takes the place of OpenSSL/LibreSSL (etc) as used on Linux.
That framework does things differently, which turns out to make life difficult:
* It seems to require the certificate for your custom certificate authority to be in the macOS keychain.
So instead of having a custom CA that can be used by just your one application when doing https calls to your own remote server... you have to install your (root) CA certificate "system wide". From rough memory, that's a potential security problem as allows your custom CA to generate certs for any domain that macOS would now accept.
* It seems to also impose it's own arbitrary standards on certificates.
It looks like anything with an expiration date of more than a year is automatically rejected.
Which for certificates embedded in applications that aren't released at least once per year (eg ours at sqlitebrowser.org) just outright kills the whole fucking thing regardless of anything else we could do.
There's no real workaround for the kind of idiocy that requires applications more than a year old not being allowed to work. :( :( :(
---
That's my rough memory of this stuff anyway, it's been quite a while since I last looked at it. Hopefully the above isn't too far off base. :)