1. 3

    This is an interesting idea. I think one reason it’s never been adopted is that it needs browser support to work well To do this right now, you’d need the auth page to trigger a p12 download and you’d have to load it manually, I suppose. Browsers have all dropped the old native support for things like CSRs (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen) and offering to store application/x-x509-user-cert mime types in the browser’s key store.

    I assume the client-side certs would be short-lived, with some equivalent of OAuth’s refresh_token. More analogous to OAuth access tokens than the typical TLS client certs.

    The big problem I see is that since the API authentication is implicit in the browser’s state when using mutual-auth TLS, wouldn’t APIs become vulnerable to CSRF attacks?

    1. 3

      Yes, and even if you have smartcard infrastructure and can make your users use one, browser UX is horrible. For example, in Chrome, if your certificate is expired, the browser won’t tell you that, unless you have the browser console open. Another issue is the (in theory) simple problem of “logging a user out”, so that say, they can hand their computer to another person and let them login to the same site under a different identity. Chrome caches the client certificate and does not provide an API for clearing that cache:


      In the world where you control your user’s full desktop experience and they have to use your software, you can say, “quit the browser to logout,” but that’s not an acceptable user experience for a commercial website.

      Of course it’s easy to imagine that Chrome would prioritize these issues if usage was more common but it’s clear that most commercials orgs in the industry are not in the mood to be the early adopters here on behalf of their users.