Verifying Access Token (JWT) in Each Service of a Microservices Architecture

Question

I have an application which is implemented using microservice architecture. There is an authentication service (A) which uses jwt standard, and there are other services in the application like S1, S2, S3 and so on. Now for example S1 receives a request, it should validate the token to see if the user is authorized or not. The validation can be achieved by:

• Sending the token from S1 to A, then A validates the token and sends the result to S1 (which is a kind of overhead)
• Validating the token inside S1 (which is a duplicate action inside every service, also requires secret key or public/private keys inside each service, for signing/verification)

I'm not asking about how these approaches work exactly. The questions is, which one of them is better? Or what is the best practice in this situation?

Answer 1

I would recommend keeping your authentication service packaged up in another microservice and communicating with it to authenticate. (Basically your first option.)

In a microservices ecosystem, you're likely to have 10s if not hundreds of applications running (ideally) pretty independent of one another. With the second option, you have added boilerplate every time you spin up a new service. But perhaps more importantly, you've coupled all of your microservices to your current authentication scheme. Best to put all of your auth behind an interface and hide all your auth logic in one, separated place.

Answer 2

I think you need to consider both solutions and think what are the tradeoffs.

Having a single service handling authorization:

• Single point of failure. If someone makes a mistake, then your entire ecosystem goes down.
• Increases encapsulation of a well known problem.
• Reduces work on all dependent services.

Implementing authorization on each service:

• Gives more independency to each service (which is the nature of "microservices")

• Gives flexibility on how you want to secured each of your services. Could vary depending on the intend of each of them.

At the end, you need to find what's your need and take a decicion based on what gives you more benefits. I just listed a few of pros and cons, but I think the idea is to invest time on this topics and then take the decision based on what you consider is best for your team.