3 ms·

If you do this you get 0 value from using a JWT over a regular session id. It's simpler and likely less work to just not use a JWT in that case.

• cogman10 4y ago
  The value add is you don't need a cryptographically secure session id generation mechanism when you work with JWTs. A simple session ID can be (and often was) forged to grant access to things end users shouldn't have. Put the session id in the JWT and now an attacker can't easily change the session they are associated with.
  • zaphar 4y ago
    generating a sufficiently random session id is not difficult. Using JWT doesn't substantially make this easier for you and operationally you are going to have to invest in significant key management infrastructure. If you don't need the stateless nature of JWT you should just not use them.
    • cogman10 4y ago
      > generating a sufficiently random session id is not difficult There are enough CVEs on this specific topic that I tend to disagree. I've been around on the internet long enough to witness a HUGE number of session hijacking attacks. [1] > Using JWT doesn't substantially make this easier for you and operationally you are going to have to invest in significant key management infrastructure. IDK about making it easier, but rather using JWTs for this makes it harder to get wrong. > If you don't need the stateless nature of JWT you should just not use them. Agreed. Use them when they make sense and not when they don't. I'm not arguing that JWTs are panacea. They are neither good nor bad, just a tool. [1] https://owasp.org/www-community/attacks/Session_hijacking_attack https://owasp.org/www-community/attacks/Session_hijacking_at...
      • dns_snek 4y ago
        > I've been around on the internet long enough to witness a HUGE number of session hijacking attacks. JWTs don't make it any harder to hijack sessions, in fact, they often make it easier. Session sniffing and man in the middle attacks don't discriminate between JWT and cookies/session IDs. Nowadays they are very hard to achieve with the vast majority of the web operating over HTTPS with optional HSTS. Cookies containing the session ID can be marked as HTTP only, unlike JWTs which are often stored in localStorage, which makes them vulnerable to extraction via XSS vulnerabilities. > using JWTs for this makes it harder to get wrong Any popular web framework these days should provide secure built-in functions to generate and validate cryptographically secure signed cookies containing the session ID. JWT libraries have had critical vulnerabilities in the past, such as allowing usage of the badly designed "alg: none" feature of the JWT specification. https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
        • zaphar 4y ago
          JWTs have been in the news a lot for trivial vulnerabilities and among security/cryptography professionals is widely regarded as a problematic standard. I would argue just as you seem to be that the surface area for ways to get them wrong is much worse than session tokens.
  • xorcist 4y ago
    You do need a cryptographically secure RNG to work with JWTs though. There's no getting around the need for randomness.
    • diroussel 4y ago
      You only need a cryptographically secure RNG to generate a key pair. Assuming asymetric keys. That private key can then be used to sign many many JWTS. Whereas generating new session ids will always need fresh entropy.
      • dontlaugh 4y ago
        That depends on the algorithm, some depend on randomness like IVs.
        • diroussel 4y ago
          Maybe you are thinking of JWE? If the signing of the JWT wasn’t deterministic, then it would be hard to verify.
          • dontlaugh 4y ago
            Correct. Some auth systems use JWE. Some even use it interchangeably with just JWS.