I think more context is needed to understand what your web application does. When you say web token, I assume you mean JWT, which uses a process of encoding/decoding and can be hacked.
If an attacker can interfere with the JWT/cookie on the client and change the user id they can become any user on your system.
Don't put any user info on the client (JWT/cookie page rendered stuff is fine), just a hash that refers to the session id. This would make it harder for someone to change ids or guess usernames. And use HTTPS for all traffic.
Its okay to use lightweight sessions, a hash for the session id and a user id in a sessions table on the server should be enough to keep track of who is who.
Most web frameworks have this problem solved so maybe look into that for whatever language you are using (unless this is a comp-sci quiz question testing your understanding of sessions/security, haha).
What I meant was don't put identifiable user information (ids, email addresses, etc.) on the client in a JWT or cookie and use that as a session identifier. If the JWT or cookie gets hacked then someone can impersonate anyone on your system.
Putting their info (email, name, etc.) on a user profile type of page should be fine if your app has a need to do that.
If an attacker can interfere with the JWT/cookie on the client and change the user id they can become any user on your system.
Don't put any user info on the client (JWT/cookie page rendered stuff is fine), just a hash that refers to the session id. This would make it harder for someone to change ids or guess usernames. And use HTTPS for all traffic.
Its okay to use lightweight sessions, a hash for the session id and a user id in a sessions table on the server should be enough to keep track of who is who.
Most web frameworks have this problem solved so maybe look into that for whatever language you are using (unless this is a comp-sci quiz question testing your understanding of sessions/security, haha).