It depends on how you define your terms. If you think of the RESTful API and the Authentication mechanism as two separate systems, you can have your cake and eat it too.

We use stateful JWT to "fail fast". That is, we can quickly reject invalid authentication, but we still look up the hash in the database before we actually use it. Our systems that do API and Auth are separate enough that the stateful/stateless distinction isn't useful.

People seem to really wiggle around what constitutes state, when it comes to auth/autz and REST.

Some people seem happy with a tiny amount of state to manage user sessions, which makes REST harder.

Other people use tokens of one flavor or another, which may have more security vulnerabilities than conventional sessions, although I'm not convinced.

Shared secret HMAC style is another alternative, although I'm not clear how to make that work with javascript clients in browsers.

Some people just throw the whole authentication question into headers and do basic auth.

Yeah, I guess it is. I only use redis for a simple cache and for worker queues. For authentication I use JWT. I store the user permissions inside the token, purely to be used by the client side (for showing/hiding interface elements). Permissions in the backend are over the database. So I tried to minimize the revoke-problem.

The stateless constraint is perhaps the most misunderstood part of REST. Fielding's dissertation states that in a REST system the messages (i.e. requests/responses) must be stateless, but clients and servers are free to keep whatever state they like. What is meant by stateless here is that you don't need additional state than what's described in the message in order to understand the message itself.

For example, a message that's missing the `Content-Type` header, but includes a body, should be rejected because you can't be sure of the body's content type. If you're expected to infer this information, in order to understand the message, the system isn't adhering to the stateless constraint.

Cookies that have session IDs, that are then parsed and mapped to state on the server side, aren't violating the stateless constraint of REST because the message contains all information necessary to understand the message itself.