Micro Service cross service dependencies

Question

Just to simplify my situation I currently have 3 micro services.

1. Authentication
2. Locations
3. Inventory

The authentication service authenticates the user and sends back a JWT access token and I use that across the other services. Its stateless and all works well.

I setup locations among some other things in the location service and this works well and as expected.

But now I am at the inventory service and I need to add some inventory but it is linked to a location. I can easily pass the locationId in the API call but I have no way of authorizing the current user to add something to that location unless I then call the location service to validate this.

This then creates service dependencies between each other and it is something I am trying to avoid at all costs otherwise you just lose most of the benefits of micro services.

What would be the recommended approach to validate that the current user has permissions for that location? The only thing I have thought of so far is either

1. Getting the location API to issue out another access token with additional claims of what locations they have access to.
2. Or issuing out another completely separate token of some kind and passing that via the header to the inventory micro service to do a validation similar to how the JWT is authenticated.

Edit

As mentioned below on providing aggregate roots (or I am assuming that means the same as API gateways) it would provide the 3rd option of another service on top to communicate to both to provide the information.

However it then leaves a 3rd service dependent upon 2 others, so I just increased my service dependencies.

Answer 1

You microservice design is poor. You are modeling (location and items) 1 class = 1 microservice and this is not a good idea.

You shoul modeling microservices like Aggregate Roots in DDD; even with its own bounded context. So, in your case, you should model an Aggregate Root with location, items and user that allows to check domain rules at item addition user action. This could be, i.e., in your Stock Context.

Of course, this doesn't mean that you should not have a Wharehouse Context in wich you can add, modify and/or delete locations and (if no need of depencies to check domain rules) the Aggregate Root is just Location class. But this is other microservice in another context.

This post should help you. It will bring you a big A-HA! in your mind after reading it.

Answer 2

While @jlvaquero provided the idea above I just wanted to list what my actual solution was and why.

It then comes down to this setup

Now the validation is done at a gateway level. The only thing I am having some degree of uncertainty of here is the fact I am now doing validation of an entity outside the service that is meant to be in charge of that domain.

The inventory service is just accepting that the user is allowed to attach to that location. But considering that the location and user validation is outside of the services domain, it fits in that it shouldn't concern itself with that validation.

Answer 3

Gateway should do only authentication and not authorizations. The authorizations are handled inside the service as the services only maintains who can access it. I would get the Inventory service to get the list of locations that the user is authorized to access.

The whole orchestration will be happening at the UI level so that the inventory services is not building a hard dependency on the Location service.

This is one approach - not sure if this will work for you.