We know one of the philosophy behind the microservice architecture is availability. So suppose we have a project that has 6 services working together. One of them is an authentication service that responsible for creating users and giving tokens and validating them. So other microservices have to communicate with auth_service. Look at the below flow for example:

user ==> microservice A ==> auth_microservice ==> microservice A ==> user 

Suppose our auth_microservice goes down for some reasons. What will happen? Microservice A needs to communicate to auth_microservice for authentication and authorization.

Here our system depends on auth_microservice. What we should do? what is the best strategy for avoiding this disaster?

Ok, I know this architecture is not perfect, but I need a solution.

3 Answers 3


By using OAuth or similar token based authentication.

First the Authentication service should be responsible for Identifying a user and issuing to them authorisation probably via an encrypted and signed token containing their permissions.

That token is then taken to the other microservices and a quick check validates the token as being authentic and trustable, or as invalid.

Make sure it contains:

  • nonce
  • issue time
  • permissions
  • sunset time (when the token becomes invalid)
  • A user identifier, but not personal information.
  • A signature using the authentication services certificate
  • Encrypt the whole thing

Use your own rules in service to determine suitability of the token. For example if its older than ten minutes the user must get a fresh token to change their phone number. But a token issued in the last 30 mins is good enough to view the phone number.

  • tnx, now I am generating tokens inside auth_microservice and other microservices send tokens to auth_microservice via grpc . you mean I can validate inside each service independently. with this approach, I lose my centralized auth logic. Mar 10, 2021 at 9:46
  • Throw the auth logic into a shared library. Chances are you use the same platform/languages anyway, or can map the library in.
    – Kain0_0
    Mar 10, 2021 at 9:59
  • 1
    @babakabadkheir The idea is that you centralize creation of the auth token in an soa, and do it in such a way that other services don't need to depend directly on the auth service - by signing it with a private key, other services can trust that it's a valid token when they decrypt with auth's public key. Throw that decryption logic in a library, and let each service determine how they want to respond to permissions - you have a central place to authenticate people, and let given domains understand whether that person is authorized
    – Delioth
    Mar 10, 2021 at 19:27

The normal solution is to apply high-availability techniques to each microservice individually, just as you would to a monolith.

So rather than having a microservice, you have multiple instances of the service running on different machines. And a failover or load balancer system for distributing requests to instances of the microservice.

The large companies that use microservices often do "blue/green" deployment of microservices as well. Rather than upgrading all the instances at once when putting a new version into production, they upgrade some of them and monitor for failures. If a problem is found, the requests can be pointed back at the old version almost immediately.

(Of course, none of this makes sense unless you're operating at huge scale, where the authentication microservice has a team of its own)


Why does microservice A depend on the authentication service? There are some (rare) valid reasons, but for the most part tokens (for example JWT) can be validated off-line.

The most that can happen here is that new users can't log in, but already logged in users will see no disruption, depending on the validity period of the tokens.

  • this is ok to validate the tokens inside each service? if I understand your answer correctly, you say we generate the tokens inside Auth microservice and validate those tokens inside each service? Mar 10, 2021 at 9:41
  • Yes, that's the way it is assumed to be for something like JWT. The tokens are cryptographically sealed, so you can validate them offline based on the known public key of the authentication service. Check here for more details: jwt.io/introduction, chapter "How do JSON Web Tokens work?" Mar 10, 2021 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.