4 ms·

I am confused. Why can't the client just drop the token and be done with it? Why do you need to store session state on the server to be "secure"?

• wglb 5y ago
  Because the server thinks that the session is still alive. The server doesn't know that the client has "dropped" the session. If the dropped token should be somehow be found again, it still has all the authority that the original session did.
  • hkai 5y ago
    This got flagged by our pentest vendor as well, but to me it sounds like a very unrealistic attack vector. If one can steal a token from your browser's storage or can intercept your HTTPS connection, then sure, yes, you have a huge vulnerability even without JWT.
    • quickthrower2 5y ago
      Could make you less secure if the token was leaked somehow (another vuln for example a cross origin type of thing) You notice odd behaviour so you log out to stop it but the attacker isn’t logged out. Also with this setup log out of all devices is not possible! Again something you’d be keen to do if seemingly attacked.
      • porker 5y ago
        I've never got my head round how log out of all devices works. It has to have a central store of all sessions?
        • lbriner 5y ago
          It depends on what auth you are using. In OpenID Connect, there are back channels that talk to each other so that all devices know you have logged out. If you are using traditional auth then yes, you would need to track session state against the user so that when they access from a particular device, you could check whether they have already logged out. Some more complex apps use a background thread to check auth status with the server.
          • porker 5y ago
            Thanks for the insight. As Google has this feature I've wondered how they get it to scale up.
    • wglb 5y ago
      > it sounds like a very unrealistic attack vector. It isn't unrealistic at all. A lot of attack vectors seem unrealistic to the victim until they happen. How realistic is it to think that a hostile actor can inject their code into a build process without touching the disk, then get that corrupted executable signed; then that signed executable is installed by 18000 users with root permission?
  • ryanmarsh 5y ago
    I’ve only done a few JWT implementations so forgive my ignorance but isn’t this what “exp” and token refreshes are for? If you don’t want to maintain a centralized session store and you don’t want long lived tokens just set the expiry to 90 seconds. When you attempt a refresh, if the user is logged out it will fail. I’m really confused by the either/or of “hit central session store on every request” or “tokens that live five minute too long are bad mmmkay”.
    • josephg 5y ago
      Huh? To track if the user is logged in (for longer than 90 seconds) you’ll need another token, used to refresh the JWT token. And you’ll need the normal session infrastructure to validate that anyway. That sounds like a very complex system to cache session tokens. You may as well just cache normal session tokens for 90 seconds in your application servers. Same result, less complexity.
• IgorPartola 5y ago
  I guess because if you have the JWT abs I have your JWT and you hit logout, I can keep using your JWT.
  • lbriner 5y ago
    I think they are saying that to get that JWT would not be easy or likely, since it would need to be used within 5 minutes as well. Although unlikely, I guess people want to know that clicking logout just does that and that there isn't a chance that some kind of hacker, colleague, nerfarious company or country couldn't continue to use your apps as you.
• stillbourne 5y ago
  Because if the client has the token its susceptible to sidejacking