Is security the only point of failure in microservice architecture?

Question

I am working on a microservice architecture application. Each microservice can live on its own, has no direct dependencies on other microservices in the system. In each microservice, we use CQRS and event sources to report changes in service status. Other services are informed of these events if they are interested and can update their data.

So far, the system is working very well. If one microservice does not work, others still work. After the interrupted service starts again, she will receive all the events that occurred in her absence and will update her own state depending on these events.

Now we need to provide our services, and for this we use IdentityServer. We have another service, our security service, which will be called by other microservices to get a token. This is the first time that a microservice must talk directly to another microservice.

My problem with this approach is that if the security server is down, the whole system is down.

I am thinking of the following solution:

Each microservice must store user data in its own database. If the user accesses the microservice, the user authenticates inside the service without remotely invoking the security service. I still need to have a security service to manage users. Changes in users will raise events again, and other microservices can update their user data. Of course, everything is with https. And perhaps to reduce redundant code for security, I could use the nuget package.

Do you think this is a smart approach?

Thank you for your advice.

Answer 1

Your decision will lead to the risk of using user data for an attacker who compromised any microservice, and not just one specific security service. I think this is a significant difference and risk that you might not want to accept.

Note that with an SSO solution similar to OAuth2 / OpenID Connect, there is no need for each microservice (Service Povider, SP in SSO) to connect to the security service (identity provider, IP) for each request. As soon as a client (a client that is a consumer of microservices) received a token from IP, the token can be checked for SP regardless of IP (for example, using public-key cryptography). This means that if the IP does not work, new access tokens will not be issued, but already issued ones will continue to work, and microservices will not necessarily talk directly to each other, only through their consumer.

Answer 2

Your solution suggests duplicating the logic and state of IdentityServer across multiple microservices. You can accomplish almost the same goal, but in a more elegant way, by creating multiple instances of IdentityServer in several geographically distributed locations to minimize the risk of failure (HA cluster). You will add more risks by duplicating this logic (even reusing the NuGet package) in several services. You still need to connect this thing to every microservice, right? This is one of the possible sources of error.

Like Gabor , mentioned in his answer, this will increase the risk of compromising the user database.

If you are concerned about the fact that errors may occur after you deploy the new version of IdentityServer, you can solve this problem by carefully checking it in an intermediate environment before deploying it to production.