Can we talk about client-side certificates? June 12, 2020 on Drew DeVault's blog

I’m working on improving the means by which API users authenticate with the SourceHut API. Today, I was reading RFC 6749 (OAuth2) for this purpose, and it got me thinking about the original OAuth spec. I recalled vaguely that it had the API clients actually sign every request, and… yep, indeed it does. This also got me thinking: what else signs requests? TLS!

OAuth is very complicated. The RFC is 76 pages long, the separate bearer token RFC (6750) is another 18, and no one has ever read either of them. Add JSON Web Tokens (RFC 7519, 30 pages), too. The process is complicated and everyone implements it themselves — a sure way to make mistakes in a security-critical component. Not all of the data is authenticated, no cryptography is involved at any step, and it’s easy for either party to end up in an unexpected state. The server has to deal with problems of revocation and generating a secure token itself. Have you ever met anyone who feels positively about OAuth?

Now, take a seat. Have a cup of coffee. I want to talk about client-side certificates. Why didn’t they take off? Let’s sketch up a hypothetical TLS-based protocol as an alternative to OAuth. Picture the following…

  1. You, an API client developer, generate a certificate authority and intermediate, and you upload your CA certificate to the Service Provider as part of your registration as a user agent.
  2. When you want a user to authorize you to access their account, you generate a certificate for them, and redirect them to the Service Provider’s authorization page with a CSR in tow. Your certificate includes, among other things, the list of authorized scopes for which you want to be granted access. It is already signed with your client CA key, or one of its intermediates.
  3. The client reviews the desired access, and consents. They are redirected back to your API client application, along with the signed certificate.
  4. Use this client-side certificate to authenticate your API requests. Hooray!

Several advantages to this approach occur to me.

Here’s another example: say your organization has several services, each of which interacts with a subset of Acme Co’s API on behalf of their users. Your organization generates a single root CA, and signs up for Acme Co’s API with it. Then you issue intermediate CAs to each of your services, which are only allowed to issue CSRs for the subset of scopes they require. If any service is compromised, it can’t be used to get more access than it already had, and you can revoke just that one intermediate without affecting the rest.

Even some famous downsides, such as CRLs and OCSP, are mitigated here, because the system is much more centralized. You control all of the endpoints which will be validating certificates, you can just distribute revocations directly to them as soon as they come in.

The advantages are clearly numerous. Let’s wrap it up in a cute, Google-able name, write some nice tooling and helper libraries for it, and ship it!

Or, maybe not. I have a nagging feeling that I’m missing something here. It doesn’t seem right that such an obvious solution would have been left on the table, by everyone, for decades. Maybe it’s just that the whole certificate signing dance has left a bad taste in everyone’s mouth — many of us have not-so-fond memories of futzing around with the awful OpenSSL CLI to generate a CSR. But, there’s no reason why we couldn’t do it better, and more streamlined, if we had the motivation to.

There are also more use-cases for client-side certificates that seem rather compelling, such as an alternative to user passwords. Web browser support for client-side certificates totally sucks, but that is a solvable problem.

For the record, I have no intention of using this approach for the SourceHut API. This thought simply occurred to me, and I want to hear what you think. Why aren’t we using client-side certificates?

Articles from blogs I read Generated by openring

The Future of Forums is Lies, I Guess

In my free time, I help run a small Mastodon server for roughly six hundred queer leatherfolk. When a new member signs up, we require them to write a short application—just a sentence or two. There’s a small text box in the signup form which says: Please t…

via Aphyr: Posts July 7, 2025

Raised Catholic

My introduction to CatholicismIn my young life, I was quite involved in Catholicism. I was raised this way by my mother, who wholeheartedly believes in it. In contrast, my father is not religious, and only goes to church for special occasions like the Chr…

via Cadence's Weblog July 6, 2025

Hare 0.25.2 released

I am pleased to announce the release of Hare 0.25.2 today. 🎉 It has been almost one year since the previous release, Hare 0.24.2, and the new release is packed with the numerous language features, standard libarary features, and countless bugfixes and small…

via Blogs on The Hare programming language June 21, 2025