Is a security service a single point of failure in a microservice architecture?

Question

I am working on an application with a microservice architecture. Each microservice can live for its own has no direct dependencies to other microservices in the system. In each microservice we are using CQRS and event sourcing to inform a state change in the service. Other services are informed about those events if the are interested and are able to update their data as well.

So far the system works very well. If one microservice is down, others are still working. After the interrupted service will start again, it receives all events happened in its absence and will update its own state depending to those events.

Now we need to secure our services and we are using IdentityServer for this. We have one more service, our security service, which will be called by other microservices to get a token. This is the first time a microservice has to talk to another microservice directly.

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

I am thinking about the following solution:

Every microservice should persist the user data in its own database. If a user accesses a microservice, the user is authenticated inside the service without a remote call to the security service. I should still have a security service for just managing users. Changes to users will again raise events and the other microservices can update their user data. Of course everything with https. And maybe to reduce redundant code for security, I could use a nuget package.

Do you think this is a reasonable approach?

Thanks for your advices

Answer 1

Your solution would introduce the risk of user data being available for an attacker that compromised any microservice as opposed to the one particular security service. I think this is a significant difference and a risk that you might not want to accept.

Note though that with an SSO solution similar to OAuth2 / OpenID Connect there is no need for each microservice (the Service Povider, SP in SSO speak) to connect to the security service (the Identity Provider, IP) for each request. Once a client (a client being a consumer of the microservices) got a token from the IP, the token can be verified on SPs independently of the IP (by means of public key cryptography for instance). This means if the IP is down, no new access tokens will be issued, but the ones already issued will continue to work, and microservices don't necessarily talk directly to each other, only through their consumer.

Answer 2

Your solution suggests duplicating logic and state of the IdentityServer across several microservices. You can achieve essentially the same thing but in a more elegant way by creating multiple instances of the IdentityServer in several geographically distributed places in order to minimise the risks of failure (HA cluster). You will introduce more risks by duplicating this logic (even by reusing NuGet package) in multiple services. You still have to wire-up that nuget thing into every microservice, right? This is one possible source of errors.

Also as Gabor mentioned in his answer, this will increase the risks of compromising users database.

If you are worried about the fact that errors can happen after deploying a new version of the IdentityServer, you can solve this by more thoroughly testing it on staging environment before deploying to production.