Authorization solutions aren’t really mentioned in your article. But it is quite easy to pull in any authorization provider which separates out the authorization concerns to a specific place and does all the heavy lifting. While many identity providers don’t do this, there are solutions like Authress which handle microservice authorization.

Specifically:

Authentication and authorization logic needs to be handled in each microservice, and this part of the global logic needs to be implemented repeatedly in each microservice. Although we can use the code base to reuse part of the code, this will in turn cause all micro services to have a dependency on a particular code base and its version, affecting the flexibility of the microservice language/framework selection.

I wouldn’t consider this remotely to be true. In general all the functionality to handle security for authentication and authorization for microservices can be and has been contained into a separate provider. While some of the more common federated identity providers may not provide that, every resource service only needs to make a single API call to an authorization as a service provider which can return a simple 2XX/4XX response to indicate success or unauthorized.

Microservices using REST also don’t need state management, that means no session identifiers, no cookies, only the single JWT. Everything else is persisted to the relevant database.