why use JWT + refresh tokens and not only JWTs???
Unanswered
Chinese Chongqing Dog posted this in #help-forum
Chinese Chongqing DogOP
i asked a similar question [here](https://nextjs-forum.com/post/1415501227738792126) already, but found myself stuck on another thing, why dont you just give the user a jwt token which is valid for 15min and also save it to the db, now the user can do stuff for 15mins and after the jwt expires we check in the db if this old jwt exsists, and if it does we just give him a new jwt and update the old one in the db, doesent this have the same security like with a JWT + refresh token? i see no difference here, other then with my method i only have to care about one cookie and not 2 different ones.
-# pls ping me if you answer
-# pls ping me if you answer
32 Replies
Chinese Chongqing DogOP
i also made a little sketch were the output is the same on both (starting at client (blue))
not sure the point on saving a jwt to db, the whole point is for it to be "stateless"
you if anything loose security
@riské not sure the point on saving a jwt to db, the whole point is for it to be "stateless"
Chinese Chongqing DogOP
i mean the jwt is stateless, it works for 15min without hitting the database and if it is expired only then we compare it with the one in the database and if they match we issue a new one and update the one in the database, so like with a refresh token just that we dont need a refresh token
i meann it solves the issue of forking refresh tokens (ie with one you can make so many new without others effected)
and it doesn't have the same security of refresh as the point is that its only sent twice over network
(not like it matters for 99% of people tho)
@riské and it doesn't have the same security of refresh as the point is that its only sent twice over network
Chinese Chongqing DogOP
thats also a issue i have,
await cookies() instantly gives me the refresh and access token so the refresh token always gets send together with the access token even if i dont need it which i guess defeats the purposeyeah
thats why i dont bother with refresh tokens if its via cookies
its more a thing in dedicated apps and oauth
Chinese Chongqing DogOP
is there any other save approach that could be used? instead of access and refresh tokens?
my aim is to make a dashboard like pterodactyl where i can manage billing and servers, i just want a secure way so users cant get access to other users infos and since i have to hit the db anyways if users go to billing or servers i can also hit the db everytime with session lookups.
my aim is to make a dashboard like pterodactyl where i can manage billing and servers, i just want a secure way so users cant get access to other users infos and since i have to hit the db anyways if users go to billing or servers i can also hit the db everytime with session lookups.
yeah, i havent read that one but it is pretty bad for being able to know what sessions your user is logged into, and then revoke
American Chinchilla
Usually how jwt IS done is either using a blacklist
Or you ignore checking access token , and simply store the refresh token in the DB
If it matches the user is logged in and can get a nee access token.
This way you only query the DB every fixed interval
However some companies even the most secure network companies still use JWT and have only access tokens that live forever lol
So it really depends, but generally you would add other safety measures
Like content policy and strict cookies, finger printing etc
@American Chinchilla Usually how jwt IS done is either using a blacklist
yeah but that point your just doing monkey patches and should just use DB/redis properly
@riské yeah but that point your just doing monkey patches and should just use DB/redis properly
American Chinchilla
Yeah, 👍. Theo uses the method of refresh token in DB
I dont think he blacklist access tokens
For his app Uploads
Realistically access token expires fast and if anyone does click a bad link theyre done for anyways not necessarily the app itself, but can add CSRF anti tokens on forms
@Chinese Chongqing Dog i mean the jwt is stateless, it works for 15min without hitting the database and if it is expired only then we compare it with the one in the database and if they match we issue a new one and update the one in the database, so like with a refresh token just that we dont need a refresh token
Milkfish
JWTs confuse me bruv.
I might be wrong, but if you do this, then whenever a user logs in, or if their JWT is ever stolen, they would effectively have access forever, since it's always updating and never actually expiring.
At least both refresh tokens and access tokens are short-lived. This is like a never ending session, and I don't know if it's safe.
I might be wrong, but if you do this, then whenever a user logs in, or if their JWT is ever stolen, they would effectively have access forever, since it's always updating and never actually expiring.
At least both refresh tokens and access tokens are short-lived. This is like a never ending session, and I don't know if it's safe.
@Milkfish JWTs confuse me bruv.
I might be wrong, but if you do this, then whenever a user logs in, or if their JWT is ever stolen, they would effectively have access forever, since it's always updating and never actually expiring.
At least both refresh tokens and access tokens are short-lived. This is like a never ending session, and I don't know if it's safe.
Chinese Chongqing DogOP
yeah, i switched to a different solution since its not really possible to request only one cookie from the client so the refresh token would get send the same like the jwt which doesent make sense for me, i now just use one session token which lasts 90 days with id:secret and hash it in my db, since i need to hit the database anyway i can also checkout the token right away.
Milkfish
okay. That makes sense
@Milkfish JWTs confuse me bruv.
I might be wrong, but if you do this, then whenever a user logs in, or if their JWT is ever stolen, they would effectively have access forever, since it's always updating and never actually expiring.
At least both refresh tokens and access tokens are short-lived. This is like a never ending session, and I don't know if it's safe.
thats why u always make the jwt with an expiry
@riské thats why u always make the jwt with an expiry
American Chinchilla
As Riske mentioned, using an expiry date helps to prevent this. But also using strict policy for example can prevent CSRF and content policy headers for XSS.