TLS allows for client certificate validation. Client certificates can be signed by the client, the service provider, or a trusted third-party CA. I'm talking about the middle option.

At a glance, it would seem to me that handing out an API key to a client would be equally (in)secure to identify that client, as when signing a CSR for that client on the service provider. The API key approach would be a LOT simpler, not having to deal with CSRs and certificate renewal etc.

Are there any differences in security between these two options?

I have to also mention here that there is complete control over client implementation, i.e. safeguarding the API key client side is under the same level of control as the client's certificates and private key

1 Answer 1


There is a difference in a non-repudiation point of view. A shared secret is known to the server, so if something bad happens, the client can claim that he did not use the secret at that time. Specifically, any admin of the server can use the shared secret to pretend being the client.

Even if the CSR is signed by the service, the private key is still only known by the client: the service nor the admins cannot use it. So the client cannot pretend that somebody else used their certificate.

The real question is what exactly is your requirement and why you want a secure authentication of the client. Because all the logs are under full control of the server. So you can prove that you got a connection from the person who owns the private key, but it would be much harder to prove that this specific connection was used to make something.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .