Help with storing user's state
Answered
neon posted this in #help-forum
neonOP
I'm setting up authentication for my next app. I have got the whole login and session token (JWT) figured out (the JWT token is stored in the cookie). But I can't figure out where do I store the user's state, whether the user is logged in or not. I am not using next-auth, but in simple terms, I am looking for my own implementation of next-auth's
getServerSession and getClientSession funcitons.Answered by Knopper gall
I think you may be confused about JWTs
A JWT is a signed payload, it is signed by the server.
The client can modify the payload, sure, but then they can't re-sign the JWT so it becomes invalid
You could intercept the JWT to 'trick the client' into being authorised, but any sensitive actions should verify the sent JWT again (which would fail as it got tampered)
You could also verify the JWT and return server components instead, so the client never has access to sensitive UI
A JWT is a signed payload, it is signed by the server.
The client can modify the payload, sure, but then they can't re-sign the JWT so it becomes invalid
You could intercept the JWT to 'trick the client' into being authorised, but any sensitive actions should verify the sent JWT again (which would fail as it got tampered)
You could also verify the JWT and return server components instead, so the client never has access to sensitive UI
6 Replies
@neon I'm setting up authentication for my next app. I have got the whole login and session token (JWT) figured out (the JWT token is stored in the cookie). But I can't figure out where do I store the user's state, whether the user is logged in or not. I am not using next-auth, but in simple terms, I am looking for my own implementation of next-auth's `getServerSession` and `getClientSession` funcitons.
Knopper gall
well usually your JWT would indicate the user is logged in, and you'd drill into the JWT to auth roles
@Knopper gall well usually your JWT would indicate the user is logged in, and you'd drill into the JWT to auth roles
neonOP
yeah, for that i created a middleware which verifies jwt. But im not sure how do I store that data, whether jwt is verified or not. Do I use a cookie, but then won't the end-user be able to modify the cookie to make themself authorized even if they are not?
@neon yeah, for that i created a middleware which verifies jwt. But im not sure how do I store that data, whether jwt is verified or not. Do I use a cookie, but then won't the end-user be able to modify the cookie to make themself authorized even if they are not?
Knopper gall
I think you may be confused about JWTs
A JWT is a signed payload, it is signed by the server.
The client can modify the payload, sure, but then they can't re-sign the JWT so it becomes invalid
You could intercept the JWT to 'trick the client' into being authorised, but any sensitive actions should verify the sent JWT again (which would fail as it got tampered)
You could also verify the JWT and return server components instead, so the client never has access to sensitive UI
A JWT is a signed payload, it is signed by the server.
The client can modify the payload, sure, but then they can't re-sign the JWT so it becomes invalid
You could intercept the JWT to 'trick the client' into being authorised, but any sensitive actions should verify the sent JWT again (which would fail as it got tampered)
You could also verify the JWT and return server components instead, so the client never has access to sensitive UI
Answer
Knopper gall
So what I'm saying, is store the users auth role (or an DB/ID link) in the JWT, the server will verify the JWT then return the relevant content (such as an admin panel) if the user is authorised
You shouldn't need to use another cookie for something else?
@Knopper gall I think you may be confused about JWTs
A JWT is a signed payload, it is signed by the server.
The client can modify the payload, sure, but then they can't re-sign the JWT so it becomes invalid
You could intercept the JWT to 'trick the client' into being authorised, but any sensitive actions should verify the sent JWT again (which would fail as it got tampered)
You could also verify the JWT and return server components instead, so the client never has access to sensitive UI
neonOP
Ah, seems like i was confused about jwt. Thank you