JWT vs. Client Certificates

Question

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!

score 7 · Answer 1 · edited Jan 30 '18 at 16:24

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.

edited Jan 30 '18 at 16:24

schroeder

123,438
55
284
319

answered Jan 30 '18 at 16:03

dFrancisco

2,691
1
13
26

isn't worthwhile to mention SSL for the JWT choice ? – elsadek Jan 30 '18 at 18:08
@elsadek Either way you would require SSL no? Granted that could be mentioned as a general need but either way both JWT and certificate option suffer from attacker sniffing traffic and replaying stolen token/certificate if transmitted over HTTP (i.e. not HTTPS). Losing a certificate is just more damaging than losing a token. – dFrancisco Jan 30 '18 at 18:28
JWTs require certificate management. If you are not signing your JWTs with a certificate you are not using them in a secure fashion – McMatty Jan 30 '18 at 21:10
@McMatty JWT's require a pre-shared secret key with the server that creates the JWT and the server that consumes the JWT. No certificate. If a single server creates the JWT before asking for it in future requests as authentication, it simply needs to store the secret key in a secure location on the server which is not hard to do. No certificate management necessary, only private/secret key management. – dFrancisco Jan 30 '18 at 21:16
@dFrancisco they allow multiple ways of securing it. Alg RS256 is a signed token using a client certificate and using HS256 opens you up to brute force attacks. I would not recommend anyone use HS256 unless they have a technical requirement to do so. For reference https://www.sjoerdlangkemper.nl/2016/09/28/attacking-jwt-authentication/ – McMatty Jan 30 '18 at 21:30
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
That's also not a brute force attack – AndrolGenhald Jan 30 '18 at 21:38
@dFrancisco not my area of expertise either, but I don't believe client certificate authentication sends any secrets over the wire. Edit: pretty sure I'm wrong about this – AndrolGenhald Jan 30 '18 at 21:40
@AndrolGenhald I (don't think) I ever said that it did. I simply meant to say sending the certificate itself over the wire (if sniffed) results in a much longer (time wise) breach than a sniffed JWT token off the wire as tokens by nature should expire for more quickly than certificates. – dFrancisco Jan 30 '18 at 21:44
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
As this site is about learning do you really want to assume the guy asking about JWTs and certificates has extensive knowledge in the subject? – McMatty Jan 30 '18 at 22:05
@McMatty I answered his question, pros and cons of JWT vs client certificates. It is un-reasonable to append (to an already long answer) a long winded explanation on the ideal implementation of JWT authentication when it was not even asked for. A basic google search could pull up thousands of results on that topic. – dFrancisco Jan 30 '18 at 22:18
1

I know this is old but it was referenced in another forum and has some confused/confusing terminology. Sending a 'certificate' over the wire doesn't compromise it. Certificates represent the 'public' portion of a key-pair. They are designed to be shared freely. It's only if the private key is compromised that you have a problem. If you are sending the private key in normal use, you are doing it wrong. – JimmyJames Oct 27 '20 at 16:22

score 2 · Answer 2 · answered Oct 27 '20 at 17:36

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.

score 1 · Answer 3 · answered Jan 30 '18 at 21:19

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

Worth noting that client side certificates, by design, require TLS on the transport layer. — Bojan Markovic, Feb 18 '21 at 12:45

score 1 · Answer 4 · answered Feb 18 '21 at 13:09

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.