JWTs are signed and after all your client somehow needs to know about the data, would be fairly pointless if it can't read it. You should read about JWTs here: https://jwt.io

well basically, the way its secure is that while signing your key and encrypting it u make sure that only your backend can read it

Thats the whole purpose of a jwt

so if someone maliciously steals a jwt from someone else, they wont be able to read its content

only your server

and tagging @Asian black bear thats why im confused even after reading. if the jwt is set up that the client can read the data then how is it secure? doesnt that mean even if you sign it anyone can decoded it, they just cant modify it. and then if it is set up to be encrypted/decrypted by the backend such as whatt i thought nextauth was doing for storing my oauth token, why am i seeing in my client side network console a /session request with my session and thus my oauth token completely decrypted as part of the request

the client cant read the actual data from the jwt

the jwt got probably decrypted from the server and send over a rsc or over headers

and the client has the decrypted value now

thats why u might see it in your request

jwt is just a extra point of security -> for example:
1. attackers get access to a bunch of jwts,
2. instead of forcing everyone to change passwords, the server just resigns the jwts making the stolen ones invalid

the attackers will never have access to the actual passwords

thats why having your discord token shared is dangerous

cause discord literally doesnt care after validating your jwt

ah i was reading it wrong, so it is sending the token cookie which contains that data and then getting the decrypted response back
which i dont want? like my client has no need for the decrypted oauth token, its only used on the backend to query the discord api
am i still missing something? im pretty amateur when it comes to security stuff so im just trying to run through my head how it could go wrong, or is it just a bad idea to STORE tokens unencrypted client side

exactly

your client doesnt need the decrypted stuff

you probably query your operations over a api

so the server has access to the cookies

from there u can securely do operations with your jwt

and the client will never have access to the content

if u want the client to have access to a portion of the jwt, u can strip the secure stuff from it and send only the stuff u need

from a server component for example

thats why nextjs is cool

going a extra step more, u can set the cookie from the server, making it a httpOnly cookie

this way even the client cant read the jwt itself

so if some bad protected websites allows script injections, the encrypted jwt cant be read

was the exactly to my first line or to its only bad to store tokens unencrypted?

atm my client has no need for any decrypted value, it is only used backend, and for the forseeable future it will only ever be used backend. so ideally id like to get session to not send anything decrypted because its not needed so why do it, but from reading the docs anything you add to the session variable in the session callback will automatically get sent to the client decrypted

ah i see

oh maybe u have to ask that specifically to the makers of the lib

i dont really work with thirdparty auths

i have my own secure implementation

nextauth is just confusing me i did find this url https://github.com/nextauthjs/next-auth/issues/7976 which talks about my issue
so looks like maybe i can just modify the jwt callback? idk ill just have to mess around ig

@gin sorry for the follow up ping, you had mentioned you have your own implementation. since it seems i am stuck with it being exposed, how would i go about encrypting it preferablly in a way that the encryption key is unique per the user/client? i am currently encrypting some other data that gets stored but that key is based off of this oauth token so cant really use the same logic here xd

well..if my goal is to just encrypt it so that its not readable to the front end i could just use a private key on the backend thats the same through out, would stop clients from seeing what the data is but wouldnt do anything if one client got another clients session data but think only way to counter that would be doing device specific authentication

yes my implementation uses end to end encryption that ecrypts everything on the server aswell, so even my server doesn't now the content in the db, in this way i have encrypted emails, passwords and userdata

For your question, yes u can sign the jwt with a private key on the server

going a little bit further, u could double encrypt the jwt, first with a general key, and the layer below with a private key saved with the userid in a seperate collection

this way the actual userdata is still bound to the unique private key

so, if something happens, purge the private keys from the db and it will be impossible to get the actual data

but i think this is too much

thats probably a bit to advanced for me, although i do have my own decrypt/encrypt function so encrypting it shouldddnt be too hard.

and yeah idrk how secure i should be trying to make this XD its not like we are storing anything crucial like payments or what not, but at the same time A) learning experience and B) i just wanna feel safe about what i make