Why do you encrypt the cookie?

[marc.bee]

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.

Source

1. What situation are you thinking of? The browser and https should do all of the lifting here.
2. Generally, leaking a JWT token is of no concern. What data inside of the JWT are you concerned about protecting?

The downside of the encryption is that:

1. it bloats the size of the cookie.
2. It does (slightly) decrease performance of the server

[tyf]

Hey there @marc.bee welcome to the community!

While I’m no Next.js expert, encrypting the cookie is part of the security model.

@marc.bee

Generally, leaking a JWT token is of no concern. What data inside of the JWT are you concerned about protecting?

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.

@marc.bee

it bloats the size of the cookie.

While true, you can opt to not store the ID token as a means to cut down on overall size.

[marc.bee]

While I’m no Next.js expert

My question should be generic to any backend

encrypting the cookie is part of the security model.

I don’t see any mention of encryption except for here which is only documenting the env variable: GitHub - auth0/nextjs-auth0: Next.js SDK for signing in with Auth0

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