Best practice to organize authorization in microse

Question

For example, I have 3 services:

• Authentication
• Seller
• Buyer

Each of them got their own databases, models, services... etc

Authentication service knows about users, user-groups, roles, permissions and creates token.

Where should I store sellers/buyers entities? On Authentication service, or on Seller/Buyer services?

How should Seller/Buyer services interact to create new seller/buyer entity?

How should Seller/Buyer services check permissions?

Seller and Buyer entities have some common fields: name, password, email..., but also each of them have their own additional fields.

Seller and Buyer interact with each other.

Answer 1

This sounds familiar to a problem I was solving recently

Assuming your services are HTTP based, then I would recommend you check out oAuth 2.0

A short copy from RFC 6749

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.

For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo- sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation- specific credentials (access token).

It simply models the authentication and authorization into a workflow between

A User

• Owns some data, hence it is also called Resource Owner
• Has credential(s)

Authorization Server

• Owns and Controls the User Identity, Credentials, and Claims
• Controls granting & denying access to User's resources (not really required in this scenario)
• Exchanges a user's credentials for an access_token that a Client can then use to access information from a Resource Provider
• Optionally grants a refresh_token that can be used to renew an expired access_token

Resource Provider(s)

• Service that has information
• Trusts the Authorization Server
• Verify access_token is valid (has not expired, signed correctly, etc.)
• Verify required claims are present (user, roles, etc)
• And Release information to a requesting Client

Client(s)

• An Application (internal or 3rd party)
• Authenticates the user via the known authorization server
• Obtains an access_token
• Uses the access_token to call resource provider(s) to obtain information

Claims Identity

A Claims Identity (explained better in more details here) is not just a username & password, it can carry many claims such as an email, a date of birth, etc. for an authenticated user, and you can use those claims to communicate any common user properties to your various services.

Shared Attributes

Now, your last questions was about linking a user (or an identity) to an entity in each service that represents some unique information in that service's context... this can be achieved by linking an existing authenticated identity and access_token to an internal representation of the user in each service.

Something like:

• A Seller Is a User
• A Buyer Is a User
• A User has (Claims, access_token)
• A Claim is a key value pair
• A Claim can be (name, email, role, ... etc)