Should the Auth Server be combined with the User Service in a microservices architecture?

Question

I am currently building a microservices based application in spring boot with the following services

• Auth server (Distributes access tokens)
• User service (User info like username, password, email, etc.)
• Various other unrelated services

When a user sends their credentials to the auth server, the auth server should verify that they are correct and then return an access token.

My question is, should I combine the auth server with the user service so looking up credentials is a simple database call, or should I keep them as separate applications and have them both point to the same shared database? Is there a better alternative?

Answer 1

What I usually do is keep them separate. Account information (first name, last name, contact data, affiliation, sex etc) is not related to authentication/authorization. Also, an account can have multiple authentication methods (i.e. OAuth, uname-pass, private key), which isn't really related to account data. So, I take them as separate entities. I know auth and account data seem the same, but they represent two very different things, with very different responsibilities, so I keep them separate. If one user should have to see some other user's first and last name, I wouldn't like to get other user's credentials out of the database (a lot can go wrong).

If you are thinking of UserService from Spring Security, it goes with Auth server.

From security stand point, having a single point of truth (auth server) and be able to fix an issue in one place is a huge advantage.

Anyhow, IMHO, account and auth can share some properties, but they are two different things - hence I keep them separate.

Hope this helps.

Answer 2

You should keep them separated, oauth is not related to identity management but to authorization delegation.

In oauth2 there are 4 roles (resource server, resource owner, client and authorization server) you are currently asking if the authorization server must be part of one microservice of the resource server which has absolutely no sense.

If I correctly got your case what you name a user corresponds to the resource owner role in oauth2 terminology, some oauth2 flows (e.g. client_credentials) directly allow a client to get an access to the resource server and there will be no users implied in any way.