Instead of directly accessing to database or key-value storage, each service in Tier 2 must use Tier 1 Data Storage Service. Target of the internal service calls are located via Configuration Service hosted independently from API Gateway. API Gateway is deployed and configured per product. Product has an apikey and apisecret.
On monolithic architecture, I was able to intercept dispathced business invocations via configured interceptors inside current executing http task. Therefore I was able to receive AuthenticationToken from business service request and decide whether the end user has authenticated via authentication service by directly querying the key-value storage.
Following the micoservice architecture, before executing business logic Business Service should make a request with transferring all original request headers to the Authentication Service, awaits its response, then parse the authentication result, and executes desired business logic then pipes to the response task. Single responsibility, fair enough.
Considering each Tier 2 services can be distributed anywhere inside the network, what options do I have in order to safely distinguish the internal and external requests between gateway and microservices?
Would this approach could be used to prevent internal service loop?
The best thing to do is to ensure that all requests are from an authenticated source. This could mean a user request, but also a 'service' user that corresponds to each microservice. If a hacker gains access to your tier2, and you have an un-authenticated API, they can wreak havoc.
Each microservice should have its own distinct user for use for unsolicited requests, but generally every API call should be passing along the user token you received from the original request.
Make sure you have some sort of context (for want of a better word) on all internal calls. This should contain an authentication token from the originator of any given request and can simply be passed on whenever you do internal requests.
You then need to perform authorization, based on the authentication token (ideally by verifying the token EVERY time), as appropriate within each micro-service.
For calls that are not due to an external user, make sure each one of your services acquires an appropriate authentication token, identifying it as the request originator.
Depending exactly on how your internal architecture looks, it may then be appropriate for a micro-service receiving a request identifying itself as the originator to result in an error.
Not the answer you're looking for? Browse other questions tagged architecture loops dependency-management microservices or ask your own question.
Where to Perform Authentication in REST API Server?