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!


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 | |
  • 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 '18 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 '18 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 '18 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 '18 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 '18 at 21:53

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 | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.