JWT token security - public key forgery prevention

Question

Question on securing JWT token integrity, given the following scenario:

1. Client sends a JWT to server signed with Client's private key
2. Server caches public key, but uses http (and not https) to retrieve the public key to validate that JWT is signed by the client.
3. Attacker intercepts the http connection, changes the public key to the attacker's public key, and sends a JWT to the server with the attacker's signature on it - misrepresenting the message as if it were sent from the Client.

Is there a way out of this? Thanks

Answer 1

Key management is a critical part of any security system. In the first arrangement. You must establish an appropriate trust model where you know who the authority is and how you trust them. There are multiple issues with the scenario you've presented:

• The client is signing the JWT--how do we trust the client?
• We are sending keys over a medium with no means of verifying certificates
• Trust can only occur if you know the client and the server--that can only happen over encrypted communications

GPG (and PGP) require secure communications when sharing public keys, but the identity of the public key is known. That's the only reason why the point to point communications can be trusted. That's not the way web sites are supposed to work. If you wanted the identity to come from the client, then implement a true PKI implementation. As long as the key is properly signed by one of your trust keys, it is good.

Instead, for web applications, you must implement the authority service that validates the user's credentials--usually requiring encrypted communications so passwords or other tokens cannot be sniffed.

• Once the user's identity is confirmed, the authority generates the JWT with a key your system manages.
• The public key is shared to all backend services as a matter of deployment and configuration--i.e. no need to send the key over any means

With this model, you know the public key and the authority of the private key.

There are more advanced approaches where you are sharing a group of public keys to handle rotating keys. This is more secure, but again, you cannot trust unencrypted communications due to the man-in-the-middle attack possibility.

Answer 2

Use of a message digest is one solution. In the request to the server, a cryptographic hash of the contents of the request can be included along with the headers. This way, if an attacker tries MITM, they won't be able to as they won't have the correct signature, even if they could trick into getting their public key instead of the real one.