Authentication and Signup with Microservices

Question

I am looking for the best practice to do authentication (login) and signup using microservices, given that microservices are not supposed to share the same data.

At the moment I am thinking:

1. Two services: Signup and Auth
2. Signup registers users, calls email service to verify, then informs Auth of user creation
3. All login operations are handled by Auth from then on

Problems with this are: should Signup only temporarily store the data until the email is verified? Or should both Signup and Auth store a version of the data. Should Signup directly call auth to inform of the new user (how to authenticate this call?)? Or should a communication layer such as Kafka be used, although that seems overkill?

I am looking for something more precise than this answer.

Answer 1

Firstly, you are likely reinventing the wheel. One of the major advantages of the microservice architecture is that it is very easy to reuse components, which is especially important for critical components like authentication, which are also easy to do wrong. Keycloak does exactly that.

Back to your question: Microservices do not mean that you should separate everything. (For example, you would use the command grep locally when needed and would not create a grepper service). So if you really want to implement your own auth system, it would be reasonable for the same service to implement both authentication and signup. The reason for that is that the activities are so tightly coupled. Seperate services should be coupled as loosely as possible.

This is also the reason for your confusion. Since the services are so tightly coupled, they have to share the data. Creating redundant data is only going to introduce more state to your services, which is undesirable from a management/scalibility perspective.

In general, microservices should offer APIs that are platform agnostic, a HTTP/Rest API being the most common and the simplest way. I would avoid using a message bus, unless there is a good reason for using it. If you send messages over Kafka and implement your pwn logic on how the messages should be interpreted, your services can not be used elsewhere, at which point, you can just develop a monolith instead.