We're planning on using JSON Web Tokens (JWT) for our authentication server, and I am currently evaluating which encryption approach to take for the JWE token.

There appear to be two options for managing the symmetric encryption key:

  1. Issuer/recipient pre-share a symmetric key and encrypt all tokens using that; symmetric key is not included in the message.
  2. Issuer generates a symmetric key per token, then encrypts the token using the recipient's public key and includes it in the message.

It doesn't seem to me that there's any inherent security advantage of either, as long a strong enough algorithms and large enough key sizes are used.

It looks like the main difference is that in the first case the recipient has to trust the issuer not to leak the pre-shared key, whereas in the second case only the recipient has the necessary decryption key. However, given the payload of this JWE token will be a signed JWS token, the recipient also must have a strong trust relationship with the issuer and must trust them not to leak their own private signing key, so this doesn't seem like a big issue.

Given option 1 produces a much smaller token (due to not having an encrypted symmetric key embedded in it) is there a good reason to prefer option 2?

  • Note that option 2 here isn't the correct alternative for asymmetric encryption - see my answer below.
    – cjk
    Commented Mar 6, 2017 at 14:28
  • I think it depends on the use case. In my case, for an OTP based application, I am creating a JWT secret using my private key & otp code generated at run time (e.g string concatenation : mysecret+otp). At the time of verification, user passes the otp received via SMS & JWT (received from https request), which I again use to create secret dynamically & verify JWT using that secret. I think it is similar to option-1 & hope, there is no issue with that. Commented Aug 24, 2018 at 0:12

3 Answers 3


I would say the main advantage of option 2 is that there is no need to distribute (or update in case it gets compromised) a pre shared key. If you can somehow make sure you have a secure mechanism of transfering the pre shared key, (i.e. there is only one person you need to do this with, and you're confident in talking to them on the phone and spelling out the key -- obviously this has security risks (phone taps, key written down on paper on the other end, etc) that you need to evaluate) I would go for option 1. However if you want to build some api interface where clients can connect and start secure connections without an out-of-band key exchange, go for option 2.


For option 1 both the issuer and the recipient have to keep the symmetric key secret. If your recipient is a multi tenant cloud service produced and maintained by a different party this may be too risky, if someone gets access to the config files or the database it will allow them to create tokens to impersonate anyone in the system.

Option 2 puts the responsibility of keeping the key secret on the issuer. If you are the recipient this alleviates lots of responsibility and security concerns as you are only holding the public key. As the issuer you get more confidence as you are solely responsible for the security of your private encryption key.

So it really comes down to how much do you trust recipient to keep the symmetric key safe, and if you are the recipient are you willing to bet your product and reputation you can keep it safe.


Just want to put this on here for people finding this via Google (currently 2nd result for searching jwt public private vs symmetric)

Option 2 here is a security leak - if the issuer encrypts a message using the receivers public key, then yes the receiver is the only person that can decode the information, but with JWT the security needed is that the JWT is completely intact and has not been modified. Encrypting with a public key doesn't do that - anyone could do the same thing and impersonate the issuer.

The real solution is to SIGN the token using the issuer's PRIVATE key, then anyone can confirm using the issuer's PUBLIC key that the issuer did indeed confirm that authority in the JWT.

  • 1
    And FWIW it's not a leak, but an elevation of privilege. :)
    – Steve
    Commented Mar 6, 2017 at 16:45
  • @Steve surely more serious as you could impersonate another user?
    – cjk
    Commented Mar 7, 2017 at 14:37
  • Impersonation is just EoP. You're going from no privilege to whatever privilege you want.
    – Steve
    Commented Mar 7, 2017 at 14:52
  • 2
    There's no leak or elevation of privilege here. See the sentence in the question "However, given the payload of this JWE token will be a signed JWS token" which verifies the identity of the issuer. So I already said we were signing it, this question was about the encryption to make it unreadable by anybody except the recipient.
    – Greg Beech
    Commented Mar 9, 2017 at 17:23

You must log in to answer this question.

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