Exactly correct, Jasen.

Shared cryptographic keys (usually one for each environment, e.g. development, integration, production, etc) are needed in order to sign or encrypt JWTs.

All JWTs are Base64 encoded, but without using a shared key to sign or encrypt a JWT its contents (or “claims”) can be decoded, read, and potentially altered.

Using a shared key to sign a JWT creates a unique cryptographic signature that is included as the final section of the JWT. Although the JWT’s contents can still be decoded and read, the intended receiver, who has the shared key, can use the key to confirm and therefore trust that the contents have not been modified by a third party, assuming a strong key, secure key exchange technique, etc. This is an important aspect of security called non-repudiation, meaning that the sender knows and can verify exactly what was sent to the intended receiver and the intended receiver knows and can verify exactly what was received from the sender.

Taking this one step further, a shared key can be used to encrypt the JWT, preventing anyone but the intended receiver from seeing or altering its contents.

Depending on the kind of information being communicated, a layered combination of these approaches can result in an appropriate level of security being applied to various kinds of messages.