Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Authorization and user microservices design

Tags:

I'm trying to design microservice from an existing application with a quite standard user management: has authentication and authorization, and stores user data.

I'm developping an Authorization server to manage user authentication and authorization using OAuth2 as authorization. On other side I have to store user's information/profile.

Question: Should Authorization server manage:

  • both authorization and user API? Thus other microservices can contact Authorization server on /me to get current user but also /users to get full list of users.
  • Or only authorization and I have to create User microservices? Thus Authorization server only exposes /me API related to user and User microservices will expose /users?

The first solution is a bit simpler but the Authorization server will become less generic (less reusable) because user application data model will be part of it (database data model of User table).


The other requirement is Authorization server should check if a user exists before authorizing it.

There is no user auto-creation, users must be invited by administrator to get access. With this requirement, the first solution is simple because Authorization server has access to user database but the second solution Authorization server implies:

  1. Share database with User service (hum don't like that)
  2. Call User service before authorization using REST API (for example)
  3. Authorization server should maintain minimal User table (can be renamed Account) and administrator will not create user on User service but only user account on Authorization server

I think 1. solution is out but any advices about 2. and 3.?

3. in first place seems the best, but if I want to switch to another Authorization server, for example a public one (OAuth2) like Google, Github, Facebook, etc... Security can be compromise because we can't control user account creation.

Any feedback?