4 ms·

JWTs are perfectly fine as a set of signed attributes if you are not using them for stateless session management (what big apps actually do this, in practice?).

JWTs are perfectly fine as a set of signed attributes if you are not using them for stateless session management (what big apps actually do this, in practice?). Most (if not all) popular JWT libraries reject "alg: none" at this point. If JWTs don't match up with your use case, don't use it! Opaque, server bound tokens are fine in many cases.

flowerlad 5y ago
> if you are not using them for stateless session management REST APIs are required to be stateless, meaning the server does not store any state about the client session on the server-side. When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. So having session state in memory won't work. There is nothing wrong in using JWT tokens with a REST service. In fact most services do just that.
- kijin 5y ago
  > When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. Distributed key-value stores have been a thing for ages. Besides, the information you are accessing and manipulating through that REST API is probably stored in some sort of database, so you most likely already have a straightforward way to share state among your frontend servers. It's only a matter of whether it's fast enough for your purpose. Most people don't even have to go "distributed" on the backend. A single Redis instance can handle upwards of 1 billion requests per day.
  - flowerlad 5y ago
    You are making my argument. You are saying there is no need for session state on frontend servers. That's my argument as well. And there's nothing wrong with JWT that prevents it from being used to identify the user or the associated backend data.
    - kreetx 5y ago
      I think you are misunderstanding the statelessness of REST. Each HTTP request is stateless in the sense that it can be understood without having previous HTTP requests around. But you can build sessions on top of that (= into your application) and that is not "against the rules". Also, with regarding to REST "front-end servers" aren't part of the discussion, but an implementation detail.
      - flowerlad 5y ago
        I am sorry, I don't agree with your interpretation. My interpretation is aligned with this: https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest-server-api https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest... "...but creates no load and consumes no per-client storage on the set of servers or on the network" So no, per-client session state would be against the principles of REST in my view.
      - flowerlad 5y ago
        This might help you: https://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions/34700703 https://stackoverflow.com/questions/3105296/if-rest-applicat...
noodlesUK 5y ago
You say that they reject alg: none, but even auth0 got caught by alg: nOnE… One of the main issues I have with JWT is that it has a fairly high degree of cryptographic agility rather than a version number that specifies a set of cryptographic primitives.

flowerlad 5y ago

> if you are not using them for stateless session management REST APIs are required to be stateless, meaning the server does not store any state about the client session on the server-side. When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. So having session state in memory won't work. There is nothing wrong in using JWT tokens with a REST service. In fact most services do just that.

kijin 5y ago
> When you have multiple servers servicing requests there is no guarantee that subsequent requests will go to the same server. Distributed key-value stores have been a thing for ages. Besides, the information you are accessing and manipulating through that REST API is probably stored in some sort of database, so you most likely already have a straightforward way to share state among your frontend servers. It's only a matter of whether it's fast enough for your purpose. Most people don't even have to go "distributed" on the backend. A single Redis instance can handle upwards of 1 billion requests per day.
- flowerlad 5y ago
  You are making my argument. You are saying there is no need for session state on frontend servers. That's my argument as well. And there's nothing wrong with JWT that prevents it from being used to identify the user or the associated backend data.
  - kreetx 5y ago
    I think you are misunderstanding the statelessness of REST. Each HTTP request is stateless in the sense that it can be understood without having previous HTTP requests around. But you can build sessions on top of that (= into your application) and that is not "against the rules". Also, with regarding to REST "front-end servers" aren't part of the discussion, but an implementation detail.
    - flowerlad 5y ago
      I am sorry, I don't agree with your interpretation. My interpretation is aligned with this: https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest-server-api https://www.ibm.com/docs/en/sdi/7.2.0.2?topic=reference-rest... "...but creates no load and consumes no per-client storage on the set of servers or on the network" So no, per-client session state would be against the principles of REST in my view.
    - flowerlad 5y ago
      This might help you: https://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions/34700703 https://stackoverflow.com/questions/3105296/if-rest-applicat...

noodlesUK 5y ago

You say that they reject alg: none, but even auth0 got caught by alg: nOnE… One of the main issues I have with JWT is that it has a fairly high degree of cryptographic agility rather than a version number that specifies a set of cryptographic primitives.