1. 5
  1.  

  2. 12

    I’ve ranted against JWT before, and that rant includes a few links and citations.

    Here’s a three-year-old discussion on this site against JWT.

    Here’s another anti-JWT article that goes into some detail.

    Here are a couple of articles explaining why JWTs as a “replacement” for session cookies are a bad idea.

    1. 2

      I would second the comment at the bottom of the email thread, would love your rant as a blog post.

      1. 1

        How do you feel about solutions like Cognito?

        1. 1

          Mixed feelings. On the one hand, I generally push people to use someone else’s battle-tested auth system rather than rolling their own. On the other hand, I dislike ones that use JWTs since they inevitably mean using a JWT-parsing library with all the attendant risks.

        2. 1

          I mostly agree with this - I think for 99% of people, using JWTs is dangerous because it’s easy to miss one small thing and mess up the security of the implementation. And most people do it because it’s easy - when you’re writing a flask service nobody wants to handle setting up sessions because that involves a whole bunch of other components that aren’t built-in.

          I’ve seen one implementation do it well: short-lived JWT access tokens, long lived session refresh tokens.

          The access tokens are signed by an auth server and can be verified by microservices while the long lived refresh tokens are just session tokens - you can get an updated JWT by talking to the auth server again. This has the advantage that auth is centralized but any microservices only need to see the short lived token to verify the user’s identity. There are limitations (you can’t immediately expire all auth tokens - you can only expire the refresh tokens, so you may have living sessions until the latest auth token expires) but when done correctly it can be a useful technology.

          1. 3

            I’ll refer you back to my “rant” – this scheme is literally just one of (signed cookies | bearer tokens) but with extra work and less safety. JWT isn’t offering anything you wouldn’t get from one of those other options, except for the “feature” of people sometimes being able to literally Jedi-mind-trick their way into your services by waving their hand and saying “You don’t require me to have a valid signature” and your servers agreeing.

            Or for a more comprehensive reply, read any of the “don’t use JWT for session tokens” articles. They tend to cover this scheme and debunk its usefulness.

            1. 2

              I think for 99% of people, using JWTs is dangerous because it’s easy to miss one small thing and mess up the security of the implementation.

              I think it’s also worth contrasting between consuming JWTs and creating them. Lots of identity providers create them and those JWTs should be pretty bullet proof (no none algos, supporting good encryption protocols). It’s their job, after all.

              Rolling your own JWT seems far more problematic to me.

              There are limitations (you can’t immediately expire all auth tokens - you can only expire the refresh tokens, so you may have living sessions until the latest auth token expires) but when done correctly it can be a useful technology.

              This post (full disclosure, written the CEO of my company) talks about JWT revocation options. May be of interest to you: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts

          2. 1

            What else people use nowadays? Macaroon?

            1. 4

              I don’t know much about it, and don’t have any experience with JWT either, but I’ve heard of this:

              https://github.com/paragonie/paseto

              1. 3

                I’ve used paseto in the recent past, and it was extremely easy to use & achieve good results with. Would strongly recommend on that alone. My crypto friends all seem to like it, too, so that seems like a winner.