4 ms·

Some concepts to think about: local introspection: validating the validity and lifespan of a jwt by checking it cryptographically. does not need to make a netw

Some concepts to think about: local introspection: validating the validity and lifespan of a jwt by checking it cryptographically. does not need to make a network call, thus very fast and a great way to perform a low stakes operation. remote introspection: validating the integrity and lifespan of a jwt by checking with the server that signed it and/or the server that issued the session. this should happen at least once per call flow, ideally as few times as possible but also every time sensitive information is accessed if you have a heavy call graph, you can do local introspection on everything in the middle. and then, when you go to retrieve pii, do remote introspection. if your token is appropriately short-lived (15 minutes), this means that an attacker can only yield information within that window with token scraping. that means that an attacker can only access data for as long as they have a foothold. i hope you have strong reporting and immutable architecture :) > If you’re building a simple website like the ones described above, then your best bet is to stick with boring, simple, and secure server side sessions. Instead of storing a user ID inside of a JWT, then storing a JWT inside of a cookie: just store the user ID directly inside of the cookie and be done with it. so basically, if your application is doing its own authn/authz (most monolithic applications), you don't need jwts.

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 ago
  The 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 ago
  Do 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 ago
    using 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.

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 ago
The 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 ago
Do 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 ago
  using 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.