Microservice Architecture - using Auth Server as a User Resource server

Question

I'm designing an application based on microservices architecture.

In this application I will need Auth microservice.

Also I will need to store some extra User information such as, perhaps, multiple addresses, avatar picture etc.

This leads to idea of having two microservices - one for Auth and another, User, which could store User extra information.

So far, I have the following ideas:

1. Allow auth service also to be a resource server that would hold User information including additional addresses, perhaps, an avatar etc. This is a convenient solution because allows to have everything related to User in one place and reduces complexity for operations such as registration of new User, deleting of User. However, this solution seems to contradict microservices concept, but as for me this solution is the most attractive.

2. Having two different microservices - Auth and User. Auth would be responsible only for handling tokens and will not store any data related to User. So when request for a token is received, Auth service calls User to receive User data and make a decision.

3. Having two different microservices - Auth and User. Auth would be responsible for handling tokens and also store a part of user information such related to Authentication (perhaps password, roles). User service will hold all other information such as additional addresses, avatars etc. This approach to me seems too complex because it requires complex delete User/create new User operations.

Now, I will need to choose one of these solutions but I'm lost and not sure which of these is the right one.

• Laiv: #3, Congratulations, you have realised that there's one more element in your model. Account. I don't know why people strive to link security against users directly when it's evident that security is a bounded context by its own. Decuple the security data from Users and your application will be ready to change the current security model by any other, without messing with the domain. Even allowing more than one security model is possible just be decoupling these 2 concerns :-)

Answer 1

3 is the correct answer.

Your Auth server authenticates users, Your User server would perhaps be better named 'UserProfiles'

You'll find that many of your users will be people with profiles, but you will also have service users for other APIs or maybe simple API keys, which also use the auth server to authenticate but have no corresponding profile.

Additionally, you will probably find that there are many out of the box Auth servers and frameworks you can use, but you UserProfile will be customised to your needs. It is often easier to add a userid to a custom profile than integrate a custom profile with a premade authentication DB