6 ms·

Why can't you just delete the cookie when the user logs out?

• jakereps 5y ago
  That token itself is still valid - regardless of whether or not their browser still has it stored.
• hermanradtke 5y ago
  The issue is not deleting the cookie. The issue is that the JWT can still be used as a valid session unless you have some sort of blocklist. Once you introduce a blocklist, you might as well ditch the JWT and use some opaque token stored in a table.
  • axiosgunnar 5y ago
    the entire article could be summed up with this post tbh
  • remram 5y ago
    Is that a problem though? Does your threat model include clients that correctly send logout requests when they're supposed to but don't delete cookies when they're told?
    • colinclerk 5y ago
      Your application should certainly have some resolution to an account being hacked or a session token being stolen. No expiry and no denylist means an attacker can cause problems until you patch your code.
    • SigmundA 5y ago
      Never trust the client, ever.
      • remram 5y ago
        If that's how you feel, don't trust them to logout when they walk away. Make those sessions short-lived and ask for the password again whenever they do something remotely sensitive.
        • SigmundA 5y ago
          If you trust the client then why sign the JWT?
          • remram 5y ago
            The opposite of "never trust the client" is not "always trust the client". Build yourself a model and find out where trust and security are required.
    • jfgiogktkt 5y ago
      You logout on a public computer, the next user undeletes the cookie (which is just a row in a profile SQLite database).
      • remram 5y ago
        Couldn't the previous user have rigged the app to not send the logout request, or way more plausibly installed a keylogger to get your password, which allows them to log in again at will? I'm not disagreeing with you, it just seems to only cover a very specific type of attack, if someone else can mess with software. And of course if they can't it is unnecessary.
• kokx 5y ago
  Because a user could simply provide the cookie again on the next request. If you still see the JWT as valid even though you deleted the cookie, the user could stay logged in during that time. Cookies are managed by the browser, hence they are ultimately controlled by the user.
  • spookthesunset 5y ago
    Depending on the site, that might be fine. For parts of the site that deal with sevitive data… just verify the token with the auth server every request line you would old school. It really depends on the site and how much you care about having a window between logout and all the tokens becoming invalid. Most sites probably have large parts where it is a acceptable to have a few minute interval.
    • wglb 5y ago
      For a secure site, it is never acceptable to having a non-zero window.
      • spookthesunset 5y ago
        So all of reddit, every page, needs to reverify its auth token every request? Like, what is the worst that is gonna happen in a five minute window between logout and the token expiring? Sure make the account management pages reverify on every request... maybe even revalidate when you perform a sensitive write action (which is probably far less than 1% of the authenticated traffic). But every read request for a normal user? You are telling me that those all need to re-verify every request? In the case of reddit, by not validating the auth token on every (non-sensitive) read request they could probably shave off 99% of the traffic going to their auth server. Better still it improves page latency as each request doesn't need to block on waiting for a response from the auth server. Faster page loads! And, since you were smart about it... all the stuff where it actually does matter that the token gets verified right away... you can do that too! It's win, win! A lot of people mis-understand JWT or see it implemented incorrectly. JWT is pretty rad, honestly.
• deleted 5y ago
  [deleted]
• SigmundA 5y ago
  Never trust the client
• jrockway 5y ago
  Because the session material could be compromised. How do you revoke tokens on lost laptops? What if you accidentally checked the token into Github and realized your mistake? What if malware captured the token? You have to be able to revoke access on the server side. You can use JWTs and have a "revoked_sessions" table that works like a normal "sessions" table. At the start of the request, check if the token is in the "revoked_sessions" table and deny access if it is. But there simply isn't a point; this has the same performance and latency considerations that a normal sessions table has ... but with many more possible ways to screw it up. "Sessions with extra steps."
  • e_y_ 5y ago
    As the article mentions in a sidenote, a time-bounded revoked sessions table is small enough to keep in memory and can be updated via pubsub for the relatively infrequent case where you need to revoke one. It's definitely more complex but at certain scales it might be worth it.
    • rsj_hn 5y ago
      The "keep in memory" part is gonna be hard as you scale to multiple servers. You run into all the issues that lead people to stick an oracle DB behind their app servers. I agree that these considerations do pan out in some cases; I'm not saying that any of these proposals can't be the right way to go depending on your overall design, but now we are squarely in optimization-land and have long given up on statelessness.
  • Alex3917 5y ago
    > How do you revoke tokens on lost laptops? Have the user change their password, and store datetime_password_last_changed on the user model. Then just treat any tokens issued before that time as expired. There are some use cases where storing tokens might be necessary, but for most startups this is probably not a good idea.
    • jakelazaroff 5y ago
      That's exactly the same as checking a list of tokens. If you need to make a DB trip on every request, what advantage are you getting from JWTs?
• wglb 5y ago
  The client may decline to delete the cookie. The server can't presume that the client will do the proper thing.