4 ms·

>> 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 expensi

>> 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.
    - cratermoon 6y ago
      > the spec allows signing algorithm flexibility The problem lay in 1. implementations blindly accepting the value in the alg field as sent by the client and 2. one of the allowed "algorithms" was 'none'. An attacker could create a JWT with the desired data and "alg" : "none" and the flawed implementations would then "validate" the data by applying "none" to verify the signature was "". Oh, and the spec required conforming implementations to accept "none". https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
      - quesera 6y ago
        Well, "alg: none" was mandatory to implement to meet the specification, but was not mandatory to accept in use. And most implementations did not include "none" in the default accepted algorithm list. But yeah, the optics of that debacle were poor. And I can sympathize with those who instinctively avoid JWT due to concern that there are other design/spec flaws lurking. (JWT is so simple though -- it's what you'd design if you designed a thing for signed, base64'ed messages and then added a couple of extra fields. Some people will respond: "So then do that instead!". :) IMO, as long as you think of JWT as a simple and standardized signed message format, with broad cross-platform support, it's perfectly suited for its purpose.
  - cratermoon 6y ago
    Think globally distributed infrastructure spread across multiple data centers and involving multiple 3rd parties.

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.
  - cratermoon 6y ago
    > the spec allows signing algorithm flexibility The problem lay in 1. implementations blindly accepting the value in the alg field as sent by the client and 2. one of the allowed "algorithms" was 'none'. An attacker could create a JWT with the desired data and "alg" : "none" and the flawed implementations would then "validate" the data by applying "none" to verify the signature was "". Oh, and the spec required conforming implementations to accept "none". https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
    - quesera 6y ago
      Well, "alg: none" was mandatory to implement to meet the specification, but was not mandatory to accept in use. And most implementations did not include "none" in the default accepted algorithm list. But yeah, the optics of that debacle were poor. And I can sympathize with those who instinctively avoid JWT due to concern that there are other design/spec flaws lurking. (JWT is so simple though -- it's what you'd design if you designed a thing for signed, base64'ed messages and then added a couple of extra fields. Some people will respond: "So then do that instead!". :) IMO, as long as you think of JWT as a simple and standardized signed message format, with broad cross-platform support, it's perfectly suited for its purpose.
- cratermoon 6y ago
  Think globally distributed infrastructure spread across multiple data centers and involving multiple 3rd parties.