[bodhi]

What are peoples thoughts on using TLS client certificates for authentication?

Given we're talking about APIs, we avoid many of the UX problems, but it feels like taking on a different set of problems than just using a bearer token. It does provide baked in solutions for things like revocation and expiry though.

[tofflos]

I'm not that familiar with TLS client certificates so I'm not qualified to say, but if you consider other developers as your users, then the UX problem remains.

Web developers in general are more familiar with other forms of authentication so unless you have a strong reason for picking TLS client certificates I would suggest picking something else.

In other words: I would be more likely to try out an API if it was based on Basic Authentication. ;-)

[fanf2]

Seriously problematic for browsers - see Garrett Wollman's article linked below, and follow the link to his previous "defence" which has a good roundup of problems https://blog.bimajority.org/2016/05/02/an-update-on-the-http...

[hdhzy]

Client certificates don't work in http2. If you use due diligence and store them in secure hardware then they could be a lot more secure than bearer tokens (cannot be exported) but I guess most people would just store a PKCS#12 file on disk and that'd make them as secure as a bearer token.

On the other hand some companies use them even for browser clients for passwordless authentication.

[Mandatum]

It's a pain in the arse for everyone involved. Adding another management layer to the stack isn't my idea of maintainability, and I'm inclined to agree with you on your point that it introduces a new set of problems.

TLS client certs are nice if everyone knows what they're doing, but in a lot of orgs that just isn't the case.