21

We have a transaction server that is connected to by different client applications. The requirement is to have a secure means of authentication for client applications to communicate with the transaction server. The two solutions being looked at are JWT and client certificates.

In your opinion what are the advantages and disadvantages of either option from a security and efficiency standpoint. I realize that this question is a bit generic and that's specifically because we want to get some more generalized ideas before moving into a specific solution considering these components are still under development.

Any advice from those who have used either technology would be appreciated!

Improve this question

4 Answers 4

Reset to default
7

For a bit of context, I have worked heavily with JWT token based authentication but have little experience with client certificates so my answer will weight biased (information and opinion-wise) to JWT.

JWT Token Pros:

  • Can be easily generated (or re-generated) and can include expiry dates/times to reduce damage due to a stolen JWT token
  • Can include "claims" in the payload to carry extra information, perhaps the role of the client device or literally any key-value pair you would want
  • Easy to transport as once encoded they are just a String
  • Vast majority of languages have libraries to do most the heavy lifting. See: libraries page

JWT Token Cons:

  • You will generally require an authentication server or a module on your Transaction server to dispense these
  • Things can get very complicated or impossible depending on how your client needs to authenticate. As long as the user has login credentials its fine as these can be used to initially authenticate the client before sending the JWT token. Otherwise, you need some means to initially confirm the authenticity of the client

Client Certificates Pros:

  • Requires a single certificate to be installed (at configuration time? Just depends) once
  • Does not require any server-side code to create and distribute certificates the same way as JWT

Client Certificates Cons:

  • If a certificate is ever compromised, it can be used in replay style attacks for as long as it is valid (and not discovered to be compromised, otherwise it could be black-listed)
  • Requires a secure permanent storage point on the client device. Unlike JWT tokens that could safely be stored in memory and ultimately destroyed at the point of client shutdown or application being closed, the certificate would need to be persistently saved in a secure location. Depending on what exactly the client is, this can be very difficult or impossible

My opinion: JWT tokens are a secure, standardized method of client authentication and I would recommend it.

Improve this answer
16
  • 1
    @McMatty Hmac SHA256 is perfectly fine, the issue there is someone wasn't validating which algorithm to use and ended up using a public key as a secret...
    – AndrolGenhald
    Jan 30, 2018 at 21:38
  • 1
    @AndrolGenhald read the entire article as its a list of multiple security flaws that can occur with JWT implementation. The section called Crack the Key talks about brute forcing.
    – McMatty
    Jan 30, 2018 at 21:46
  • 1
    @dFrancisco Momentary brain-lapse. When I was referring to sending secrets I was thinking about the certificate itself, and you're entirely correct.
    – AndrolGenhald
    Jan 30, 2018 at 21:49
  • 1
    @McMatty Ok, but really, anyone who knows what they're doing is going to use a random value with at minimum 128 bits of entropy for the Hmac secret. I suppose you could argue that client certificates are harder to screw up that badly, but I don't know enough to really say in that case.
    – AndrolGenhald
    Jan 30, 2018 at 21:51
  • 1
    @McMatty HMAC SHA-256 with an adequately chosen secret key (i.e. high entropy) would not be brute forcible. A secret such as a 32+ character, crypto-randomly generated string would take longer than the entire existence of the universe to brute force. Bad developers will always screw up implementations, that does not make the theory behind it weak.
    – dFrancisco
    Jan 30, 2018 at 21:53
2

I stumble across this in trying to help someone on another forum and the answers here give information about client certificates that is, at best, misleading if not incorrect.

First things first.

What is a client certificate?

A client certificate is (in typical parlance) an X.509 certificate like the one that let's your browser trust this website. What makes it a 'client' certificate is that it was signed by the certificate authority for the purpose of "Client Authentication (1.3.6.1.5.5.7.3.2)"

In other words, the CA has confirmed the certificate for that use. It's otherwise like a server certificate in all other ways. In fact, a single certificate can be signed for both "Server Authentication (1.3.6.1.5.5.7.3.1)" and client authentication.

Does sending a certificate potentially compromise it?

No! Click on the little lock next to the URI in your browser and look at the certificate. Have you compromised stack exchange? Not in the slightest. Certificates are inherently public. They contain no secrets.

In either a certificate authentication scenario (client or server) it's the possession of the private key that is considered proof of identity. If your private key is leaked, you have an problem. This is true whether this is a client or a server certificate.

In the process of authenticating with a certificate (server or client), no secrets from the private keys are exchanged. They are also immune to replay attacks which is something you need to consider when using JWTs.

What if I have different roles?

Aside from what it can be used for, client certificates are generally not used to confer authorization. They establish identity. How that identity is mapped to rights is a separate issue.

Why aren't client-certificates used much for client authentication?

Mainly because creating, signing, and, managing a private key securely is beyond most users. I think this could change as physical secret management components become more common.

When are client-certificates a good option?

When you have robust PKI in place. Additionally, I think it's important to have a good handle on, at least, the basics of public-key security. For instance, if you are running a web-server that needs to act as a client in web-service interactions. If you already have a server certificate to manage, there's not much more additional overhead to managing a client-certificate as well (or using a single certificate for both.)

In this scenario, there's also no user around to type in a password or show their face or swipe a finger. It's probably running on a rack in some server farm. How are you going to authenticate this host to the third-party to generate a token? If you are using a password or other secret that you are continually sending in order to get a token, I question the wisdom of approach.

Ideally you would have some sort of HSM which stores the secret and never exposes it externally. That kind of approach is become more common and affordable.

Improve this answer
2

The point that I feel is being missed here is that JWT and SSL client certificate authentication are not really directly competing technologies.

JWT token is a competing technology to session cookies, other bearer tokens and other similar short-lived tokens like Kerberos tickets/tokens, it is not a primary means of authentication but a token that is used for subsequent requests after a successful primary authentication was already made. To obtain a JWT token set after expiry with no refresh, the client must first authenticate by some primary means of authentication, and these are commonly some form of user/password based authentications.

Conversely, SSL client-side certificate is a primary means of authentication. Like a user/password pair in the example above.

This means that it's even feasible that JWT token(s) could be generated to a client that successfully authenticated with a SSL client-side certificate, and then for the token to be used as a means to authenticate subsequent requests.

In fact for performance reasons (certificate authentication was considered expensive) this scenario of authenticating with SSL certificate with subsequent requests using some form of a short-lived token (commonly using session cookies but "roll your own security thing" bearer tokens containing encrypted important per-request data weren't unheard of, which is basically what JWT came out from) are how SSL certificate authentication was traditionally used in web applications.

Improve this answer
2
  • All answers prior to this one are useful, and then this gentleman's answer looks at the question from a different angle, and speaks volumes. My question now is: if the external services that need to call my REST API do not need any specific authorization (roles/permissions) that distinguish them when accessing my API, do I really need to bother with adding a JWT implementation? wouldn't the certificate-based mutual authentication be sufficient? ~ I would still need to worry about a hacker compromising a client certificate and calling me, but that would be the same concern with JWT.
    – sOltan
    Oct 12, 2022 at 23:11
  • 1
    Yes, you are correct on both accounts (yes it would be enough, and no, JWT doesn't add additional security). What JWT can add, though, is more context by embedding data about the authenticated "user" so that you don't have to, e.g. fetch it from a DB and that needn't be auth context but "profile" type context as well.
    – Bojan Markovic
    Oct 14, 2022 at 10:45
1

This cannot be answered without understanding your environment more.

  • Is this all within your own domain or are these externals connecting to your service?
  • Do these services require a different set of permissions from each other?
  • Are these services use to delegate a user identity that is use downstream?
  • How are these services communicating to each other? REST? Binary?
  • What is the tech stack you are working with?

Client certificates are useful as a way to authenticate but if your requirement is to have different permissions for services accessing your own service a client certificate by itself is not going to help. As mentioned above you will need to manage certificates you have issued - but this constrant exists with JWTs that require to be signed as well. If you have multiple certificates for externals you will

JWTs are useful if the consumers have different permissions and are accessing your service via REST. If the communication isn't REST then don't bother with JWT's. You will need to manage the signing certificate in JWTs as well. If you are going to use JWTs be aware of the weaknesses they have:

  • Algorithim attacks against libraries that respect the none value
  • JWT replay attacks
  • JWTs require TLS on the transport layer
  • Some JWT frameworks allow you to attack the system by switch algorithim types from RS256 to HS256 and signing with the public key

There is nothing wrong with JWTs when implemented correctly, its just people can screw up the JWT implementation. I'm bias because I am currently trying to address JWT patterns in my own organization that lead to security holes because validation ignored expiry dates...

Improve this answer
1
  • 1
    Worth noting that client side certificates, by design, require TLS on the transport layer.
    – Bojan Markovic
    Feb 18, 2021 at 12:45

You must log in to answer this question.

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