Without considering any other security measures:

• The client authenticates with the identity provider and receives a signed JWT
• When the request hits the API Gateway, the gateway checks the signature with the auth service to make sure it hasn't been tampered with (whether this is internal or external — imagine if one of your servers was compromised, you still don't want it to be able to forge a JWT with any rights beyond what the service is supposed to have)
• If the JWT is valid, the gateway forwards the request to the service and the service can trust it without validation (I think. We haven't gotten to this part yet.)
• Requests with invalid JWTs are dropped
• The API Gateway can also handle refresh tokens invisibly.
• A compromised API gateway obviously could then forge JWTs so if you want you can have each service check signatures on their own, but the advantage of the gateway is that you have a single point of vulnerability to harden rather than trust each service developer to correctly validate the token on their own.

So you can write the validation part once. I happen to be tech lead on a project to write this mechanism, so it's pretty fresh in my head.