Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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