i see. got it

these go into jwtPayload as userType: 'standard', isProvider: true

and the same for session data

yea. I see not problem with putting userType and isProvider in JWT payload

I hope I answered your question about the getting userId and userRole from my code snippet above.

Yeah, that makes sense. Is it dangerous to add 'id', 'username', 'email' to session data?

you can add anything to session data as that is only store in your DB.

Ahh, I see, yeah so it's secure. Got it And also if I have application logic based on userType: 'admin' (which is in jwt payload) is this insecure, as for example I can have some sensitive routes that only work for admin (like changing user account), is it dangerous to decide this from jwtPayload, if it is where should I put 'userType'

it's not dangerous.

Because the when you call

getSession

, the JWT signature is verified. Only if that verification succeeds, will the function return the session object

What if someone makes a payload with userType: 'admin' and can now use app as admin?

If someone changes the userType to admin on the frontend, then the JWT verification will fail

and

getSession

function will throw a try refresh error

the verification will fail because the user will not know the change in signature that is required when they change the contents of the JWT (since they do not have the private signing key).

I see, so the data cannot be changed. But it can be seen, so I can store 'admin' securely, but I shouldnt store anything I am worried that others will SEE

exactly!

Also, there is an error in the docs which says u r supposed to put the userId in the jwt payload.. u don’t need to do that (see the code snippet I sent above). I will fix the docs error

Hey SuperTokens, was looking into HashiCorp tools and I liked some of them, was wondering if it's possible to integrate SuperTokens with HashiCorp Vault https://www.vaultproject.io/ or would the two not work well together?

So hashicorp vault is used to store secret keys. We can provide a way to store the JWT secret key in it. But don’t do that yet.

However, with hashicorp vault, even if u store this key in it, u still require another key to actually access the vault. And if you do that, then you are not really solving security. You are just passing on the responsibility from one key to another.

I've asked this question before but it might be good to have some more clarity: If I authenticate user in supertokens (login), or register, the req.headers have sAccessToken, sRefreshToken, sIdRefreshToken. Therefore these all exist with every request made by user. So is it not dangerous to allow the sRefreshToken and sIdRefreshToken to be sent with every request?

IE with every request, you must send sAccessToken, sIdRefreshToken, (because if you dont it throws error)

And Does /refresh work with only sRefreshToken or does it need both? (seems to work with just 1 as well)

So all APIs except for /refresh need sAccessToken and sIdRefreshToken. sIdRefreshToken by doesn’t give access to anything. So mainly sAccessToken is the critical token here

only sRefreshToken is needed for the /refresh API.

The frontend SDK will take care of sending these tokens for you.

Hey so another question, right now I went into psql and

drop table sessions;

and

drop table past_tokens

Then I did supertokens stop dev, supertokens start dev

But the requests I make with old session is still working

How comes?

is session stored in cache?