3 ms·

Invalidation of any sort, including token revocation, is fundamentally a stateful operation. Either you are deleting session state or statefully blacklisting so

Invalidation of any sort, including token revocation, is fundamentally a stateful operation. Either you are deleting session state or statefully blacklisting something that's a packet of self-contained state (e.g. JWT by id). Heck, even expiration just reduces the revocation into the universally shared state that is time. My point is, you always have state. If you care about that state being anything but _the current time_ (e.g. just letting tokens expire and not worrying about revocation), you need shared storage.

tptacek 8y ago
If you always have state, what's the point of making tradeoffs to get closer to "statelessness"? I see clearly why some small subset of applications benefits from carefully minimizing shared state among components. It is not at all clear to me why pseudo-statelessness is a good default.
- andrewstuart2 8y ago
  I'm not sure you're actually asking for my opinion, or just making a point, but IMO, the "statelessness" most people describe with respect to web services simply means that a single request already has as much as possible of the information required (outside of current time, securely fetching/validating public keys, etc) to process the request. The point is that it's easier for distributed systems as a whole when clients hold onto their client-specific state, rather than a minimal token that the server, likely being load balanced for availability, must exchange for that state with yet another service in yet another stateful/authenticated request/response manner.
  - tptacek 8y ago
    My subtext is that gains from moving state from the server to the client are often swamped by the first serverside database round trip that has to be done to service requests. So, you see ActiveRecord Rails applications using JWT, and it's like: the benefits of "statelessness" are not rationally why this got deployed.

tptacek 8y ago

If you always have state, what's the point of making tradeoffs to get closer to "statelessness"? I see clearly why some small subset of applications benefits from carefully minimizing shared state among components. It is not at all clear to me why pseudo-statelessness is a good default.

andrewstuart2 8y ago
I'm not sure you're actually asking for my opinion, or just making a point, but IMO, the "statelessness" most people describe with respect to web services simply means that a single request already has as much as possible of the information required (outside of current time, securely fetching/validating public keys, etc) to process the request. The point is that it's easier for distributed systems as a whole when clients hold onto their client-specific state, rather than a minimal token that the server, likely being load balanced for availability, must exchange for that state with yet another service in yet another stateful/authenticated request/response manner.
- tptacek 8y ago
  My subtext is that gains from moving state from the server to the client are often swamped by the first serverside database round trip that has to be done to service requests. So, you see ActiveRecord Rails applications using JWT, and it's like: the benefits of "statelessness" are not rationally why this got deployed.