Why are sessions worse than tokens in a microservice architecture?

Question

JSON Web Token

Why are sessions not used in microservice architecture? I see two problems
1) Instead of verifying the token itself, the microservice needs to knock on the auth microservice, which creates a load.
The scale of this problem varies from one project to another. On the one hand, the load may not be too large. On the other hand, by reducing such a load, the ability to quickly manage authorization is lost - all changes in the rights / roles of the user are transferred to the lifetime of the token (or not, if you create the same load on additional checks in the database)

2) Microservices are often scattered on different domains, and cookies do not support cross-domain requests.
We store the session-id in the same place as the tokens === the problem is not specific to sessions.

Answer 1

On the one hand, the load may not be too large.

Just twice the minimum - one additional session verification request for each user request. In addition, at some point in time, the “auth microservice” will die under load and will need to be scaled somehow. If you run additional instances with a common base, then the base becomes the bottleneck. If you use different bases, you will get synchronization problems.

Answer 2

There are a million reasons, but I'm just wondering how you are going to manage sessions in a stateless world?) The correct answer is no way, they are for stateful