As a developer I do have some understanding of OWASP, I am also a member of OWASP community, official due paying one. Anyway, what I may not understand is information security in that I am not a security engineer and so I pose the following question:

Is it necessary to encrypt and encode a JSON Web Token?

In my experience, no secure or confidential information should be in a JSON Web Token anyway, outside of the id and email of the user. I can imagine a customer such as a bank freaking out about that, but what can someone do with an email? The password is salted and hashed and also at least in the NodeJS world that is my wheelhouse, JSON Web Token is tamper resistant.

I can verify that a token was valid by using the signing signature and if it fails due to tampering then the services will no longer trust it, that simple no? Why would it be necessary to encrypt it, Encode it And whatever else an overzealous engineer can think of? What problem is it solving or what use case is it handling that is not already built-in? Is it because in other programming languages there are no libraries built-in that can run a jwt.verify() on the JWT?

Could the case described in this post be what the institution is trying to solve?

JWT(Json Web Token) Tampering

I understand that for a customer for whom this is a big deal, encrypting the cookie contents is an option, but would that be overkill?

1 Answer 1


JWTs can easily be encrypted when necessary - most libraries support it by default.

There are actually multiple kinds of JWTs. There are two that are probably the most common:

  1. JWS (plain text payload with a signature for validation)
  2. JWE (everything is encrypted).

The JWS is much more common so often when people refer to a JWT they are just referring to a JWT with a signature. Indeed, there were a few years where I always thought that a token with a signature was the only kind of JWT.

However, encrypted ones do exist, so if you did want to encrypt your JWT you wouldn't want to take your JWS and encrypt it yourself. Rather, you'd just want to use a library that supports JWE out of the box. Here's an example of a library that let's you choose between signatures and encryption (as well as a third kind).

Understanding their use cases

So you can encrypt your JWT, but why would you? To answer that question is't important to keep in mind that encryption and signatures have two different purposes: a signature makes the underlying data tamper proof while encryption makes it private (and as a side effect, tamper proof).

Therefore if all you care about is making your payload tamper proof then a signature is sufficient, and has the benefit of being easier to understand and use. As a quick example, the ability to view the payload itself may help with debugging from time-to-time.

However if you also need your data to be private, then encryption is obviously necessary. You mentioned your payload "only" containing a user id and email, and that such information is not especially sensitive, but in some jurisdiction that qualifies as PII and leaking it may result in heavy fines (aka GDPR). Therefore some organizations may choose to protect even just that, or they may store additional information in the JWT that requires privacy. It just depends on your you case, and since JWTs are so flexible they are used in a wide variety of ways, so being able to choose between just signatures or full encryption can be helpful.

Do you need your JWTs to be encrypted? Only you can decide that. If you are only storing a user id and an email then probably not. However, you can store much more than that, and people often do, so it will simply depend on your use case and your own risk appetite.

You must log in to answer this question.

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