5 ms·

External services use jwts pretty often, so if you have to handle jwts anyway, using jwts means that there's only one primitive, set of libraries, and concepts

by zemo 2y ago

External services use jwts pretty often, so if you have to handle jwts anyway, using jwts means that there's only one primitive, set of libraries, and concepts for your devs to know. "You don't need all of that!" sure but you probably already have it somewhere in your codebase and it's pretty universal. You also probably don't utilize every feature of http itself, that isn't a cogent argument against using http. JWTs are supported by a large number of tools, libraries, middleware appliances, etc; there's a huge ecosystem out there to support it. You also might delegate auth to a third party like Auth0 or FusionAuth so that you don't handle any PII, because all of the PII is handled by a vendor, and you only store application-specific data. "You want to implement logout" means a few things; in most apps you just ... have the client forget the token and you go about your day and it's fine. "but what about if a nefarious actor stole the token!!!" you might say, but hand-rolled session tokens have the same problem. "You want to turn off access for all users" is something you can do in http middleware; e.g., I have used middleware that do things like "only allow through requests that have jwts with the 'admin' role in their claims because we have turned off the system from users for downtime", and that works fine. (specifically I wrote a traefik plugin to do this in an afternoon). "You want to ban a single specific user really quickly" is a thing JWT won't do out of box.

tptacek 2y ago
The problem isn't the mechanisms inside of JWT (though they are gross and worth avoiding on their own), it's the systems-level tradeoffs you have to make to use them idiomatically, particularly around refresh tokens and revocation. If you read this and think "this doesn't apply as long as I have to use JWTs for some service I rely on, anyways", you missed its point.
- zemo 2y ago
  refreshing the refresh token is always a database hit, and in the case of using a third party like Auth0 or FusionAuth, you can invalidate refresh tokens at the individual and at the user level. Saying "the refresh token is the real token" as the article does is pretty misleading; the refresh token always goes to the same system that would accept the username/password, but the jwt itself gets carted around to other systems. So again, in the auth0/fusionauth case, the refresh token is sent to auth0/fusionauth, not your app, so even without any particular knowledge of what's going on, the application developer is forced to utilize them in different ways. There's a big assumption in this article that you're talking about a monolithic system where logins are processed by the same application that handles all requests. Even if you do prefer to structure your application as a monolith and avoid microservices, once you delegate auth to a third party or a system separate from your app, the bearer token versus refresh token thing starts to matter a lot. I think there's a cyclic thing that's been happening for years where people in the security community like to talk about how bad jwt is, but then not produce anything that meets application developers needs in a meaningful way. I spent years avoiding jwt and ultimately found avoiding jwts wasn't actually a good use of my time.
  - tptacek 2y ago
    This still doesn't engage with the point. "Refresh tokens" are not a natural feature of every session scheme. They're required by stateless JWTs because JWTs are motivated by migrating authN into its own independently-scaled microservice, and because online revocation is difficult in stateless schemes. If you just use your framework session system, you don't ever think about refresh tokens. That's the point the article is making. It's not that JWT makes refresh harder, it's that it makes it a thing at all.
    - zemo 2y ago
      right so then the argument is less about "should you use JWTs" and more about "should you use stateless session tokens". > JWTs are motivated by migrating authN into its own independently-scaled microservice that's definitely one use-case, although I don't actually think having auth in a separate microservice under your own custody is the dominant use-case. The auth being in an entirely separate database means PII is in an entirely separate database, which can be a useful access control mechanism, or in the case of using a third-party auth service, means that there is no PII in databases under your custody at all. It makes the situation of "developers can access all data created by the software that they work on" really easy to implement while also maintaining "developers do not have access to all of the PII" as an access barrier. I think "I just use Auth0/FusionAuth and don't think about it" is actually the dominant use-case, and every third party offering that kind of developer experience utilizes stateless session tokens to make that happen. > If you just use your framework session system, you don't ever think about refresh tokens. right, but now the problem of keeping PII data access rules separate from your application domain data is an additional thing you have to engineer and think about securing, so I think the article is underestimating some of the negatives of that tradeoff; I've never seen a framework with a built in session system that did a good job of keeping access to the PII separate from the application data.
      - tptacek 2y ago
        You wrote a comment upthread that misapprehended the post you were critiquing. I was motivated to offer some corrections. I'm less interested in the philosophical argument you now propose, except to say that PII segregation has only very rarely been the reason I've seen people adopt stateless tokens. It is still easier to segregate data using stateful token schemes than with JWT. But I don't want to pretend we're still having the same conversation that started up thread. I assume you take my point, that if you think "I already have to do JWT so I don't save anything by not using them everywhere" rebuts the post, you've misread it a bit.
- notnullorvoid 2y ago
  Having authn stateless whether with JWTs or not is a bad idea. By extension refresh tokens are a bad idea. Doesn't mean JWTs are a bad idea, if used as a general auth token they are fine. Implementing revocation of JWTs also isn't very hard but you need somewhere to store the revocation state.
  - tptacek 2y ago
    Sorry, none of this is responsive to what I just wrote. I had a particular complaint about the critique I responded to, that's all.
- Aeolun 2y ago
  I’m not sure what you are trying to say here? That dealing with refresh token expiry revocation for a single system (and two sessions) is better than dealing with expiry and revocation for 3? I see some strong arguments for standardizing on a single one.

by zemo 2y ago

tptacek 2y ago

The problem isn't the mechanisms inside of JWT (though they are gross and worth avoiding on their own), it's the systems-level tradeoffs you have to make to use them idiomatically, particularly around refresh tokens and revocation. If you read this and think "this doesn't apply as long as I have to use JWTs for some service I rely on, anyways", you missed its point.

zemo 2y ago
refreshing the refresh token is always a database hit, and in the case of using a third party like Auth0 or FusionAuth, you can invalidate refresh tokens at the individual and at the user level. Saying "the refresh token is the real token" as the article does is pretty misleading; the refresh token always goes to the same system that would accept the username/password, but the jwt itself gets carted around to other systems. So again, in the auth0/fusionauth case, the refresh token is sent to auth0/fusionauth, not your app, so even without any particular knowledge of what's going on, the application developer is forced to utilize them in different ways. There's a big assumption in this article that you're talking about a monolithic system where logins are processed by the same application that handles all requests. Even if you do prefer to structure your application as a monolith and avoid microservices, once you delegate auth to a third party or a system separate from your app, the bearer token versus refresh token thing starts to matter a lot. I think there's a cyclic thing that's been happening for years where people in the security community like to talk about how bad jwt is, but then not produce anything that meets application developers needs in a meaningful way. I spent years avoiding jwt and ultimately found avoiding jwts wasn't actually a good use of my time.
- tptacek 2y ago
  This still doesn't engage with the point. "Refresh tokens" are not a natural feature of every session scheme. They're required by stateless JWTs because JWTs are motivated by migrating authN into its own independently-scaled microservice, and because online revocation is difficult in stateless schemes. If you just use your framework session system, you don't ever think about refresh tokens. That's the point the article is making. It's not that JWT makes refresh harder, it's that it makes it a thing at all.
  - zemo 2y ago
    right so then the argument is less about "should you use JWTs" and more about "should you use stateless session tokens". > JWTs are motivated by migrating authN into its own independently-scaled microservice that's definitely one use-case, although I don't actually think having auth in a separate microservice under your own custody is the dominant use-case. The auth being in an entirely separate database means PII is in an entirely separate database, which can be a useful access control mechanism, or in the case of using a third-party auth service, means that there is no PII in databases under your custody at all. It makes the situation of "developers can access all data created by the software that they work on" really easy to implement while also maintaining "developers do not have access to all of the PII" as an access barrier. I think "I just use Auth0/FusionAuth and don't think about it" is actually the dominant use-case, and every third party offering that kind of developer experience utilizes stateless session tokens to make that happen. > If you just use your framework session system, you don't ever think about refresh tokens. right, but now the problem of keeping PII data access rules separate from your application domain data is an additional thing you have to engineer and think about securing, so I think the article is underestimating some of the negatives of that tradeoff; I've never seen a framework with a built in session system that did a good job of keeping access to the PII separate from the application data.
    - tptacek 2y ago
      You wrote a comment upthread that misapprehended the post you were critiquing. I was motivated to offer some corrections. I'm less interested in the philosophical argument you now propose, except to say that PII segregation has only very rarely been the reason I've seen people adopt stateless tokens. It is still easier to segregate data using stateful token schemes than with JWT. But I don't want to pretend we're still having the same conversation that started up thread. I assume you take my point, that if you think "I already have to do JWT so I don't save anything by not using them everywhere" rebuts the post, you've misread it a bit.
notnullorvoid 2y ago
Having authn stateless whether with JWTs or not is a bad idea. By extension refresh tokens are a bad idea. Doesn't mean JWTs are a bad idea, if used as a general auth token they are fine. Implementing revocation of JWTs also isn't very hard but you need somewhere to store the revocation state.
- tptacek 2y ago
  Sorry, none of this is responsive to what I just wrote. I had a particular complaint about the critique I responded to, that's all.
Aeolun 2y ago
I’m not sure what you are trying to say here? That dealing with refresh token expiry revocation for a single system (and two sessions) is better than dealing with expiry and revocation for 3? I see some strong arguments for standardizing on a single one.