It is not necessarily a bad idea but I believe it is a little bit over complicated. From the information you have given us, I do not understand the need for the gateway at all.
First off, I will assume you have a separate service/server acting as an authentication server, consuming user credentials and spitting out (lets say) signed JWT tokens that vouch for the role and authenticity of each user. Then when the client wants to access run a query on one of the micro-services, it can fetch a JWT token from the authentication server if it does not already have one, then pass this JWT token in the authentication header in a request directly to the micro-service.
The micro-service can then verify the signature on the JWT token with the same algorithm used to sign it (for example the HMAC-SHA256 algorithm). If the signature is valid, then the micro-service checks the role supplied in the JWT token and either fulfills the request or rejects it.
The issue with your method is the possibility of circumventing the gateway and making requests directly to the micro-service. For example:
--------- -------------
----> Queries ----> Gateway ---- RPC ----> Microservices
--------- -------------
^
|
----> Attacker Query -------------------------
Where the attacker passes no JWT token and the micro-service will still fulfill the request.
The only good reason to use a gateway as you explained is if there is no way for the person forming the query to know where this micro-service resides and it/they must use the gateway to direct their query to the micro-service. In which case, unless you can absolutely guarantee that no request except requests from the gateway can reach the micro-services, you will need to check tokens on both the micro-services and the gateway.
Hope it helps!