Is this a valid approach for microservices authorization?

I’m considering a microservices approach for when the services commonly need to enforce data access controls as appropriate within each service. Is it a viable approach to:

a) Have all microservices authenticate to the AS and request an access token upon startup / token expiration;
b) Pass their token as JWT head in all service calls to peer microservices;
c) When handling a service call, validate the token signature only (rather than going back to the AS), and then evaluate the claims in the JWT as appropriate within each service.

Is this already a known and accepted pattern? Are there major flaws with it, particularly around ©? I like the idea because it seems simple yet performant and scalable … but then I’m not a security person :).

I’m not a microservice (MS) nor security expert. I was just wondering though aren’t MS lightweight and run “on demand”? Meaning, what would constitute startup for a MS and would you end up going to the AS each time the MS is invoked anyway?

I don’t think there is something wrong with your idea. It’s a totally valid form of protection of you service APIs.

Thanks, I just wanted to be sure this doesn’t go against important best practices or has any serious security flaws.

Don’t know about other firms but our microservices run 24/7 and are a mix of RESTful APIs “on the outside” combined with async Streaming APIs “on the inside” continually updating each other based on subscription interests. In this kind of environment it would be debilitating to have to continually check every invocation against an Authorization Service, so having services validate claims on their own is very attractive.