5 ms·

Used jwt for our web app before - changed to session cookies. To make jwt secure for web apps it feels like you are reinventing session authentication.

tptacek 6y ago
That's a point a lot of people have made, because it's basically true. JWT is a bit of a cargo cult.
- ravenstine 6y ago
  JWT is the authentication equivalent of blockchain. Besides a handful of things, people try to apply blockchain to problems that aren't real. JWT is using cryptography to solve a problem that doesn't exist, which is that storing and retrieving user sessions on the server is burdensome, even though it's one of the least expensive computations you can make on a server. In fact, unlike blockchain, I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. It just sounds really awesome until you realize that, no matter what, you're going to need to keep and fetch some information about the user on the server, and that it's really not helpful at all to offload user data into a client side token. As someone who used to be enthusiastic about JWT, I kind of wish it would die in a fire. Cookie auth is much easier to implement without the need for a 3rd party library and is also more secure.
  - lemonspat 6y ago
    >> solve a problem that doesn't exist, which is that storing and retrieving user sessions on the server is burdensome, even though it's one of the least expensive computations you can make on a server. I've never heard anyone say that's the problem, rather the issue is the network latency + dependency of hitting a cache/database for every future request. It's not a problem for everyone's apps, but pretending it's never a problem for anyone is shortsighted. Session cookies are just fine for many/most apps, and JWTs add new problems, so I dont recommend them. YMMV
    - cratermoon 6y ago
      Cookies also have domain restrictions. The client won't send a cookie from domain foo.bar.com to baz.bar.com, unless you set your cookie domain to *.bar.com, which may be bad for other reasons. Even if you get you cookie domains right, there has to be a single source of session truth across the system. This gets to be complex in distributed systems. On the other hand, a client can usefully send a JWT to any other service that has the secret key to validate it, and once validated, the information the service needs can be in the JWT itself, so there's not session lookup needed. It's the difference between giving a friend your parking stub so they can go pick up your keys from the attendant and bring your car back vs giving the friend a copy of your key and having him get the car from wherever it might be.
      - combatentropy 6y ago
        > there has to be a single source of session truth across the system. This gets to be complex in distributed systems. This sounds like a database. Or if that's too slow for you, a Redis cache. I try not to make blanket statements about software infrastructure, because we all work on a variety of systems. However, I'm having a hard time thinking of scenarios where session cookies are too hard or too slow.
        quesera 6y ago
        JWT is just a format for passing signed authentication/authorization data between two systems, possibly through untrusted channels (e.g. web browsers, mobile apps). If the receiver trusts the signer, they can use the data. Sometimes the two systems cannot share a database, or a cookie. Like everything else, JWT is sometimes used inappropriately. And of course it's not the only way to pass signed data between two systems. Sometimes it makes sense to create your own equivalent that supports only the pieces you need. One popular criticism (and historical security risk) of JWT is that the spec allows signing algorithm flexibility. This is easily mitigated, but of course any tool that can be used improperly, will be, by someone. But honestly, JWT is straightforward, simple, and has good library support across all popular languages. It's a good choice for an API that you expose to groups outside your organization.
  - tester756 6y ago
    > I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. I used it for cross-server auth sign-in to B.com from A.com > It just sounds really awesome until you realize that, no matter what, you're going to need to keep and fetch some information about the user on the server, and that it's really not helpful at all to offload user data into a client side token I guess you always must unless you want to skip permission validation and stuff.
  - mooreds 6y ago
    > I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. What if you aren't using a browser? What if you explicitly want to know that the contents of the auth token aren't modified? What if you want to work with a IdP that only provides JWTs to offer centralized authentication and user management? > Cookie auth is much easier to implement without the need for a 3rd party library and is also more secure. As long as you are in the browser, sure! In many cases you can use secure cookies and server side sessions and they work well. But as soon as you get into more distributed or larger systems, reaching out to multiple APIs, JWTs may make sense.
    - dchest 6y ago
      What if you aren't using a browser? There's no difference between browser authentication via a cookie and app authentication via a token. The cookie stores the session token, the app store the session token. What if you explicitly want to know that the contents of the auth token aren't modified There is no content in an auth token — it's a random number. What if you want to work with a IdP that only provides JWTs to offer centralized authentication and user management? When there's no choice, there's no choice.
      - chromatin 6y ago
        > There is no content in an auth token — it's a random number. Wait what? Auth tokens may contain (signed) claims, and I believe this is what grandparent poster was referring to.
        dchest 6y ago
        That’s what I’m saying - just don’t do this and you won’t need signed tokens.
  - rad_gruchalski 6y ago
    Have you heard of UMA2?
  - tinus_hn 6y ago
    If you have for instance a service which displays hundreds of images on a page, using cookie authentication which hits the database every time is quite slow. Using some kind of cryptographic token that can be validated without the database hit is much faster.
combatentropy 6y ago
Many agree. There was an article discussed in 2016, https://news.ycombinator.com/item?id=11895440 https://news.ycombinator.com/item?id=11895440, and again in 2018, https://news.ycombinator.com/item?id=18353874 https://news.ycombinator.com/item?id=18353874.

tptacek 6y ago

That's a point a lot of people have made, because it's basically true. JWT is a bit of a cargo cult.

ravenstine 6y ago
JWT is the authentication equivalent of blockchain. Besides a handful of things, people try to apply blockchain to problems that aren't real. JWT is using cryptography to solve a problem that doesn't exist, which is that storing and retrieving user sessions on the server is burdensome, even though it's one of the least expensive computations you can make on a server. In fact, unlike blockchain, I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. It just sounds really awesome until you realize that, no matter what, you're going to need to keep and fetch some information about the user on the server, and that it's really not helpful at all to offload user data into a client side token. As someone who used to be enthusiastic about JWT, I kind of wish it would die in a fire. Cookie auth is much easier to implement without the need for a 3rd party library and is also more secure.
- lemonspat 6y ago
  >> solve a problem that doesn't exist, which is that storing and retrieving user sessions on the server is burdensome, even though it's one of the least expensive computations you can make on a server. I've never heard anyone say that's the problem, rather the issue is the network latency + dependency of hitting a cache/database for every future request. It's not a problem for everyone's apps, but pretending it's never a problem for anyone is shortsighted. Session cookies are just fine for many/most apps, and JWTs add new problems, so I dont recommend them. YMMV
  - cratermoon 6y ago
    Cookies also have domain restrictions. The client won't send a cookie from domain foo.bar.com to baz.bar.com, unless you set your cookie domain to *.bar.com, which may be bad for other reasons. Even if you get you cookie domains right, there has to be a single source of session truth across the system. This gets to be complex in distributed systems. On the other hand, a client can usefully send a JWT to any other service that has the secret key to validate it, and once validated, the information the service needs can be in the JWT itself, so there's not session lookup needed. It's the difference between giving a friend your parking stub so they can go pick up your keys from the attendant and bring your car back vs giving the friend a copy of your key and having him get the car from wherever it might be.
    - combatentropy 6y ago
      > there has to be a single source of session truth across the system. This gets to be complex in distributed systems. This sounds like a database. Or if that's too slow for you, a Redis cache. I try not to make blanket statements about software infrastructure, because we all work on a variety of systems. However, I'm having a hard time thinking of scenarios where session cookies are too hard or too slow.
      - quesera 6y ago
        JWT is just a format for passing signed authentication/authorization data between two systems, possibly through untrusted channels (e.g. web browsers, mobile apps). If the receiver trusts the signer, they can use the data. Sometimes the two systems cannot share a database, or a cookie. Like everything else, JWT is sometimes used inappropriately. And of course it's not the only way to pass signed data between two systems. Sometimes it makes sense to create your own equivalent that supports only the pieces you need. One popular criticism (and historical security risk) of JWT is that the spec allows signing algorithm flexibility. This is easily mitigated, but of course any tool that can be used improperly, will be, by someone. But honestly, JWT is straightforward, simple, and has good library support across all popular languages. It's a good choice for an API that you expose to groups outside your organization.
- tester756 6y ago
  > I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. I used it for cross-server auth sign-in to B.com from A.com > It just sounds really awesome until you realize that, no matter what, you're going to need to keep and fetch some information about the user on the server, and that it's really not helpful at all to offload user data into a client side token I guess you always must unless you want to skip permission validation and stuff.
- mooreds 6y ago
  > I can't think of any real world scenarios where a JWT is superior to cookie auth over HTTPS. What if you aren't using a browser? What if you explicitly want to know that the contents of the auth token aren't modified? What if you want to work with a IdP that only provides JWTs to offer centralized authentication and user management? > Cookie auth is much easier to implement without the need for a 3rd party library and is also more secure. As long as you are in the browser, sure! In many cases you can use secure cookies and server side sessions and they work well. But as soon as you get into more distributed or larger systems, reaching out to multiple APIs, JWTs may make sense.
  - dchest 6y ago
    What if you aren't using a browser? There's no difference between browser authentication via a cookie and app authentication via a token. The cookie stores the session token, the app store the session token. What if you explicitly want to know that the contents of the auth token aren't modified There is no content in an auth token — it's a random number. What if you want to work with a IdP that only provides JWTs to offer centralized authentication and user management? When there's no choice, there's no choice.
    - chromatin 6y ago
      > There is no content in an auth token — it's a random number. Wait what? Auth tokens may contain (signed) claims, and I believe this is what grandparent poster was referring to.
      - dchest 6y ago
        That’s what I’m saying - just don’t do this and you won’t need signed tokens.
- rad_gruchalski 6y ago
  Have you heard of UMA2?
- tinus_hn 6y ago
  If you have for instance a service which displays hundreds of images on a page, using cookie authentication which hits the database every time is quite slow. Using some kind of cryptographic token that can be validated without the database hit is much faster.

combatentropy 6y ago

Many agree. There was an article discussed in 2016, https://news.ycombinator.com/item?id=11895440 https://news.ycombinator.com/item?id=11895440, and again in 2018, https://news.ycombinator.com/item?id=18353874 https://news.ycombinator.com/item?id=18353874.