As mentioned in the article you might want the token to be read by the users. Such as issuing a token with a expiry date that you want the user to regenerate. Although If anything the JWT libraries should have encryption enabled by default.
- your system is distributed
- you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes
- the JWT contains attributes useful to the system (e.g. role, user ID, etc.)
You'll probably still be keeping track of a public key of whatever's signing it (to verify authenticity), but that isn't a secret. And then you can still securely trust
if you don't have a shared data store, or its not fast enough, then you're doing the wrong thing with the wrong tools
> you don't want to be keeping a decryption key secure and in-sync across many (and potentially less-trusted) nodes
keeping shared secrets, which are very high read:write ratio, and change daily or less, should be childs play. If its not, then your security protocols are wrong. Key rotation must be simple and quick if you want your system to scale. When you get to 100 people, you'll be leaking keys weekly.
KMS, Vault and a few others are your friend here. There are off the shelf systems for this.
> the JWT contains attributes useful to the system (e.g. role, user ID, etc.)
having these public can be alright, assuming that you've properly mapped, scrubbed and checked for leakage. However, you shouldn't be reliant on user supplied stuff for this. You simply cannot trust the user.
If you need jwt for caching data, then you have a much bigger architectural problem. The stuff you are storing in JWT needs to be easily and quickly accessed. If its not, you either have a DB or a messaging system issue.
Now, if you are encrypting the whole token, then its less of an issue. But, using it to store anything other than a UUID and a issue time, you are asking for trouble.