That’s a good point, I was specifically addressing “stateless auth” as an issue of persisting authentication related state on the client side vs. the server side, as opposed to “the authentication system has no state”, since that’s usually the framing of the question.

In general authentication/authorization isn’t just a binary in or out. For example, you might have to reauthenticate to access password or 2FA settings in your account, so now you have multiple authenticated states. So I made my comment from the assumption that you probably need to decorate the user’s authentication “state” with extra information for your service. In those cases, I was suggesting to only carry that info in the token if you need to cross service boundaries with it, such as if you have multiple front end micro services operating on independent data stores.