微服务的API授权

Question

I have a multi-tenant project which will be calling multiple microservices to perform specific tasks.

I want the microservices to understand which DB to play with from the request being sent as the microservices will be used by every tenant, however, tenants will have their own DB. I have another solution which has a Web project which deals with API key management.

Let's say for example the API key management is sitting on domain: portal.example.com

When tenant.example.com calls microservice at microservice.example.com I want some middleware to listen out for the request on the microservice side and get the APIKey from the request, validate it by checking the portal.example.com services and if the APIKey is valid, grab the tenant for this API key and determine the connection string to use for the microservice.

I feel as if this isn't efficient as it requires too many calls just to determine the connection string to use, can anyone think of a better method of determining a connection string but also validating an APIKey?

Answer 1

The nature of the issue seems to require some more information with regards to some business decisions and architectural decisions.

But with the information you've provided so far, I would say that the connection strings you're referring to could potentially be a problem for data leaks as well. Given that if there are errors in the authorization service that sends the wrong connection strings, you may accidentally connect your client to another database rather than the actual client that made the request. Second point to this is that it also makes the authorization service a single point of failure. If it fails or if a malicious user gets access to it, all your tenants are affected.

Instead of letting the architecture handle this, one thing that may be worth evaluating is to use OAuth's client credentials to authenticate different applications; each application reflects a different set of database parameters. During the OAuth authentication phase, it will redirect the user to the correct application. In summary, a single set of applications deployed for each tenants where tenants are authenticated via OAuth.

A slightly different alternative is to deploy and replicate the entire stack that you use for one tenant for another tenant with their respective database credentials. I would advocate for this only if you're limited by development resources.