With the traditional session system where only the session ID is stored on the client possibly even encrypted, the user won't be able to assume the identity of another user or escalate their privileges without accessing the database or the session store directly.

But with JWTs, it seems once the attacker gets a hold of the private signing key they can do huge amounts of damage. If we store user IDs in the JWT, couldn't they simply sign themselves a token for an arbitrary user and act on their behalf? Contrasting this to say an SSL certificate being stolen, which would allow MITM attacks this seems almost an order of magnitude worse. They would not even have to sniff any traffic or modify requests, they could just pick whichever user they want, and completely undetected access the system.

I do realize that private keys are meant to be private, and if I lose my SSH key and the attacker takes over my SSH key they can do whatever they want. But IIRC there have been many cases of SSL certificates being leaked (or stuff like Heartbleed), but that at least doesn't directly allow the user to assume arbitrary identity. With JWT it seems like we're putting everything into one basket and nothing happens to it.

Is this a real security concern? Are there ways of mitigating the issue, other than not using JWTs altogether? Or am I missing something?

I really like the idea of passing around a token with claims between services, but at the same time it feels a little like encrypting all your company's private data, posting it publically on reddit and thinking I hope they won't break the encryption.

  • 1
    This is like asking "why aren't we scared of our house key being stolen?" It's a known risk so people protect them with the appropriate level of security Apr 16, 2020 at 23:31
  • I had a similar question with some nice discussion here: security.stackexchange.com/questions/173391/…
    – u9kV-6J
    Apr 17, 2020 at 0:30
  • 1
    The big difference between cookies or ssh client keys and JWT signing keys is where they are stored. The JWS signing key normally lives on the relatively trusted server (or third system). It is more critical to be protected, but also easier. (However keep in mind a JWS signed bearer token is basically the same as a session cookie and can also be lost)
    – eckes
    Apr 17, 2020 at 10:19
  • @eckes Thanks for being understanding of my silly question. The JWS signing key normally lives on the relatively trusted server (or third system) this feels like a critical piece of information I didn't think of and it makes so much sense! I thought that an exploit in my app could leak my JWT token, but having a separate signing service with less attack surface area seems like a great solution at mitigating the threat. Apr 17, 2020 at 11:27

1 Answer 1


You ask actually multiple question within a single post:

  • Risks connected with unauthorized access to private key
  • You are mixing different processes: message/authorization signing (in JWT) and securing communication channel (SSL)
  • Trust to encryption strength

To signing and private keys: Of course there are risks. There is whole industry around this, with standards, practices etc. It is impossible to name everything related to it. How to mitigate risks? Again, too broad question. Just some random hints: limit physical access of persons to hardware, "need-to-know" principle, access control and regular reviews, identity management, audits, layered security, short living certificates for JWT signing keys , e.g. 1 month, and their CA chain long living.

To encryption strength (quote: I hope they won't break the encryption): Of course, except one time pad there is no perfect encryption. I'd suggest you to ask about reliability at another site, Cryptography SE, not here. The guys will explain you why one can rely on AES, RSA, ECC and what are conditions for this (particular modes of operation, role of randomness), what are the risks.

You must log in to answer this question.

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