4 ms·
no, you need to store the jwt in a cookie(or local store) because the jwt is signed. if you would have only cookie with user id then anyone would be able to pre
by hknmtt 4y ago
no, you need to store the jwt in a cookie(or local store) because the jwt is signed. if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid.
- Huh1337 4y agoThe alternative isn't storing user ID and sending it around but generating a unique session token that's stored for example in your DB. See how PHP does it (session_start etc).
- eurasiantiger 4y agoDo not persist or store access tokens anywhere but in-memory. You can use a session cookie as a refresh token, and use it to get a fresh JWT whenever you need.
- parker_mountain 4y ago> Do not persist or store access tokens anywhere but in-memory. Using short lived ATs is one defense against this happening, such as if an attacker compromises one of your services and starts scraping tokens off of it. Ideally, the services should also have some sort of checks (such as service accounts), to ensure that only approved services can talk to each other.
- hknmtt 4y agousing two tokens makes sense only if you have cqrs system. otherwise it's a complexity that brings no value.
- parker_mountain 4y ago> if you would have only cookie with user id then anyone would be able to pretend to be anyone by manually setting the cookie with some user's uid. That's what session id (as mentioned in the article) is for.