The JWT token is already signed and does not require encrypted. The secure signing is enough to prevent tampering. Beyond that, there is no need to encrypt the cookie.
Browsers encrypt it while it is in transit (HTTPs), so it can’t be cloned.
Browsers also implement appropriate handling to prevent XSS, not that encryption would help that.
If for some reason the cookie is leaked/sniffed, contents cannot be inspected by anyone except the server the cookie was originally intended for.
When you say JWT, are you referring to the ID token or access token? Leaking of an access token especially is definitely a security concern.
In general a JWT token token should not contain an access token. This is what I mean when I said that leaking the token is should* be of no concern.
Secure authentication is provided by the JWT having been signed by Auth0 (whom we trust). The user’s ID inside the JWT token is trusted as the user’s genuine ID because we can validate auth0’s signature. That’s the security model of Auth0 as a service.
And then any encryption between the user and the backend is provided by HTTP encryption (HTTPs).
I do see that ours does contain an access token, and that it is used to query our own API server.
We DO give this access token to the client in the clear so that the client can query our API server! This is fine and normal behaviour. The client is what is called a “public client”. It is the user’s key, so giving it to the user is okay. It’s like how you show us our keys on your dashboard. You wouldn’t call that a “leak”.
Ref: Access Tokens