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?

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

Share your feedback about developing with Go

Help shape the future of Go by sharing your thoughts via the Go Developer Survey

via The Go Blog January 18, 2023

Status update, January 2023

Hi all! This month’s status update will be lighter than usual: I’ve been on leave for a while at the end of December. To make up for this, I have some big news: we’ve released Sway 1.8! This brings a whole lot of improvements from wlroots 0.16, as well as som…

via emersion January 16, 2023

SourceHut will (not) blacklist the Go module mirror

Update 2023-01-31: Russ Cox of the Go team reached out to us to address this problem. After some discussion, an acceptable plan was worked out. The Go team is working on deploying an update to the “go” tool to add a -reuse flag, which should substantially re…

via Blogs on Sourcehut January 9, 2023