3 ms·

I mean, to be fair, the article literally calls out a fairly reasonable checklist. Do you maintain a database of JWT session tokens for refresh and revoke? Do

I mean, to be fair, the article literally calls out a fairly reasonable checklist. Do you maintain a database of JWT session tokens for refresh and revoke? Do you have a real session that you load for every user every request anyway? If the answer is 'yes', then the answer to 'use JWT' isn't 'it depends'. It's no.

_heimdall 2y ago
The author here seems to be arguing that you should effectively never use JWTs. That, in my opinion, is a mistake. JWTs have absolutely been over-hyped for the last 8-10 years, but they do have a use and you don't have to be at the scale of Google for it to be the right approach. Software isn't as simple as creating a checklist of a few basic categories and saying there is always a right or wrong answer. The answer should be "it depends" because there are many more factors at play when deciding something as fundamental as authentication and authorization.
- meindnoch 2y ago
  Ok, then show us an example scenario where using JWTs makes sense, while the author's checklist says it doesn't.
  - _heimdall 2y ago
    I may not have been clear there. I'm not saying the author's list is wrong, I'm saying its incomplete. For starters, the blog post leads with the premise that the answer is always "No". Even ignoring that as playful banter, the checklist is way to broad to be universally true. > You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request. > You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request. > You need additional relationships between the user object and other objects in the database. You hit the database on each request. > Your service does anything at all with data in the database. You hit the database on each request. These all assume that I authorization data and that the user data lives in the same database. I may store my own user object with a unique ID that references an authenticated user, while the author flow is actually managed by an entirely different service (whether first party or third party). I also may have my user data stored in a separate database, say for legacy reasons or data security/integrity requirements. Not every database is crested equal, its totally possible that one database is a better fit for user data while a totally different database is needed for application data. Coming up with a list of broad scenarios and claiming that if you check any one there is never a reason to pick JWTs over sessions is misguided and overly simplistic. Context always matters. edit: formatting
    - meindnoch 2y ago
      >These all assume that I authorization data and that the user data lives in the same database Please tell us how the following assumes that authorization data and user data lives in the same database: "You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request."
      - _heimdall 2y ago
        It doesn't have to assume that, again because context matters. If authorization data is stored outside my database, I may not store anything related to that user other than their unique ID. I may not know anything about the JWTs because a middleware talking to the external authorization service authorizes a request before I ever query my database. I could also store valid JWTs in my own database or in a caching layer, say with redis for quick access. There's nothing wrong with that, but without more details on what someone is building and what it needs to be designed for there is no absolute right or wrong answer.
        meindnoch 2y ago
        I don't see how anything you said would refute OPs premise, that if you want proper logout [1] in your app, you can't use JWTs without constantly querying whether a particular JWT should be accepted or not, from which it follows that this query mechanism may as well be a traditional database with a "sessions" table. How you organize your data, your services, your middleware, etc. does not change this the slightest, hence are irrelevant. ---- [1] proper logout is instant (this invalidates the "just use a JWT with short timeout!" argument), and prevents session stealing (this invalidates the "just throw away your JWT to logout" argument)
        _heimdall 2y ago
        > may as well be a traditional database with a "sessions" table. Isn't that kind of the point though? I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. If logout can work either way, and in all likelihood logout isn't a performance concern as long as its secure, you may have other use cases and requirements in an app that do make JWTs a better fit. I still don't understand how the argument here can be that there are no cases for JWTs, or that the list of "its" in the original article can be bulletproof no matter what else is going on in a project. That's unnecessarily absolute and leaves no wiggle room for competing priorities and constraints.
- jakjak123 2y ago
  JWTs has been both overhyped and overused, by myself as well. But after working with JWT authentication for so long, it felt very strange to go back to sessions stored in a database. Suddenly every service we have needs a db connection setup to go verify the sessions. No more stateless and authenticated services. But I still agree JWTs have been overused. One of the things I have used it for that I found the most useful is probably just storing some smaller pieces of signed state during parts of a data transfer, like just bridging between two systems or in-and-out of a browser without needing to setup a database.

_heimdall 2y ago

The author here seems to be arguing that you should effectively never use JWTs. That, in my opinion, is a mistake. JWTs have absolutely been over-hyped for the last 8-10 years, but they do have a use and you don't have to be at the scale of Google for it to be the right approach. Software isn't as simple as creating a checklist of a few basic categories and saying there is always a right or wrong answer. The answer should be "it depends" because there are many more factors at play when deciding something as fundamental as authentication and authorization.

meindnoch 2y ago
Ok, then show us an example scenario where using JWTs makes sense, while the author's checklist says it doesn't.
- _heimdall 2y ago
  I may not have been clear there. I'm not saying the author's list is wrong, I'm saying its incomplete. For starters, the blog post leads with the premise that the answer is always "No". Even ignoring that as playful banter, the checklist is way to broad to be universally true. > You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request. > You need to be able to block users entirely, so you check a “user active” flag in the database. You hit the database on each request. > You need additional relationships between the user object and other objects in the database. You hit the database on each request. > Your service does anything at all with data in the database. You hit the database on each request. These all assume that I authorization data and that the user data lives in the same database. I may store my own user object with a unique ID that references an authenticated user, while the author flow is actually managed by an entirely different service (whether first party or third party). I also may have my user data stored in a separate database, say for legacy reasons or data security/integrity requirements. Not every database is crested equal, its totally possible that one database is a better fit for user data while a totally different database is needed for application data. Coming up with a list of broad scenarios and claiming that if you check any one there is never a reason to pick JWTs over sessions is misguided and overly simplistic. Context always matters. edit: formatting
  - meindnoch 2y ago
    >These all assume that I authorization data and that the user data lives in the same database Please tell us how the following assumes that authorization data and user data lives in the same database: "You wanted to implement log-out, so now you’re keeping an allowlist of valid JWTs, or a denylist of revoked JWTs. To check this you hit the database on each request."
    - _heimdall 2y ago
      It doesn't have to assume that, again because context matters. If authorization data is stored outside my database, I may not store anything related to that user other than their unique ID. I may not know anything about the JWTs because a middleware talking to the external authorization service authorizes a request before I ever query my database. I could also store valid JWTs in my own database or in a caching layer, say with redis for quick access. There's nothing wrong with that, but without more details on what someone is building and what it needs to be designed for there is no absolute right or wrong answer.
      - meindnoch 2y ago
        I don't see how anything you said would refute OPs premise, that if you want proper logout [1] in your app, you can't use JWTs without constantly querying whether a particular JWT should be accepted or not, from which it follows that this query mechanism may as well be a traditional database with a "sessions" table. How you organize your data, your services, your middleware, etc. does not change this the slightest, hence are irrelevant. ---- [1] proper logout is instant (this invalidates the "just use a JWT with short timeout!" argument), and prevents session stealing (this invalidates the "just throw away your JWT to logout" argument)
        _heimdall 2y ago
        > may as well be a traditional database with a "sessions" table. Isn't that kind of the point though? I'm not saying JWTs are a better answer for logout, only that JWTs can still support logout and they both similarly require a database transaction. If logout can work either way, and in all likelihood logout isn't a performance concern as long as its secure, you may have other use cases and requirements in an app that do make JWTs a better fit. I still don't understand how the argument here can be that there are no cases for JWTs, or that the list of "its" in the original article can be bulletproof no matter what else is going on in a project. That's unnecessarily absolute and leaves no wiggle room for competing priorities and constraints.
jakjak123 2y ago
JWTs has been both overhyped and overused, by myself as well. But after working with JWT authentication for so long, it felt very strange to go back to sessions stored in a database. Suddenly every service we have needs a db connection setup to go verify the sessions. No more stateless and authenticated services. But I still agree JWTs have been overused. One of the things I have used it for that I found the most useful is probably just storing some smaller pieces of signed state during parts of a data transfer, like just bridging between two systems or in-and-out of a browser without needing to setup a database.