when i am sending JWT to micro-service, do i need to authenticate if token is valid for every request on every micro-service running?

what is the best way to handle authorization while building micro-service?

Write your answer…

6 responses

Above Picture A is telling about how the activity will fall for authentication process and Picture B defines how the micro services helps you.

When a end your user jumps into your application and tries to login we will get a token and this token will be sending a request to the services to identify.


We also faced similar situation while planning the migration to cloud.

We have 12 micro-services, routed through API gateway (Zuul). Every micro-service is stateless (No JVM/application based sessions in our case, as JAVA is used for MS). Whenever the request passes through the API Gateway an application wide custom session is created and the data is stored in an external Redis Data store, and the required micro-service first verifies the data for the request in Redis and then serves the data.

Now, at API Gateway we have implemented Authentication filters (Pre Request & Post Request filters - JWT implementation also relies on same), where we are managing the authentication and validity of users. (JWT, SAML, or any kind of mechanism you can use. )

End User ----> API Gateway (Zuul Server with Pre & Post request filters) ---- Session Data in Redis Data Store -----> Micro-service Hit.

Our micro-service only contain code to access and verify session data while session management is done at API Gateway itself. .

If you can provide the language, framework used and deployment infrastructure planned. So, actual things can be figured out.


You should make your microservices talk to each other with an API endpoint in between (i.e instead of sending messages directly to each other, they first send the message to an API endpoint first, which in turn will deliver it to the other microservice). So, if microservice A wants to talk to microservice B, it should first make a request to an api end point, let's say /sendMessage. Now, /sendMessage will take care of all the authentication jazz and then call microservice B.

Show all replies

Well, i thought you might have considered service discovery or reverse-proxying the request somewhat beneficial; which don't apply when using a messagebus.

I think I'd prefer

  • authenticate at the gate (api-umbrella, public-graphql service, whatever)
  • authorisation per service (as this allows true separation)

I'm still not sure whether to pass along a JWT like structure with all consumer details or that each service requests consumer details (like permissions) to a dedicated consumer service. Based on performance it probably depends on how many requests the consumer service needs to handle vs the overhead of possibly sending around needlessly the JWT. And, if not using JWT internally, how do you authenticate the payload, so that a bug might not creep in the consumer details and be passed around wrongly.

Reply to this…

Yes, the token will be validated server side for every request. The server validation will provide also user information given by the token to be used next in server API code.

JWT validation will check only if the token is valid and return its value (JSON object), it is a very fast process that do not consume resources. Send an Authorization : Bearer <token> request header as standard procedure.

JWT is one of the best way for authorization as you can create RESTful solutions. (do not depend on web sessions anymore)

You may check the JWT first when you receive a request, validate it and next route the request to the module that handle it with added token information.

Successful login should generate authentication token, and every service request should pass this request for authentication/authorization. Once service (common method to do this using decorator) validates request then process data/business logic.

Show more responses