As we know, there are so many different stakeholder, consumer, providers are involved in microservice architecture, so the obvious question arise that how secure are service ! Each service has to have their own security implementation within service itself. Therefore, we can build business fearlessly depending on those services.
As per core microservices design principal each microservice is independent and self sufficient in terms of handing request and sending response. That says if anything goes wrong, there is no one from outside who can help to diagnosis the system and fix it.
At the same time, we need to understand we have to serve business faster, that’s why the microservices architecture is becoming popular and been adopted in software development practice, now regarding security, the question is whom to trust and how much to trust!
So more security we implement in each request, the architecture become more complex, and then to match with constantly changing business demand often we prefer faster delivery over security, unless, the service is dealing with direct money.
All services are served on HTTPs ,you may be interested to understand how https works. Now we consider following scenario while designing a food delivery system microservices.
Service API is stateless, so if we depend on session data after user login like any normal web application, then we may have following concerns, because in microservice architecture scenario every server has its own database, and always perform validation with their own business logic and many other dependency factors.
When user login to system and place an order!
Is there any bad history about the user, or any pending order? Based on previous user token if there is a pending order, which has been delivered and received successfully by now! so we cannot make decision based on previous token, we have to make another call to user microservice to get the latest user token (which is again been generated by third party API).
Order has been delivered and received by customer, "delivery service" database has been updated successfully, but "order management service" database still not updated (for whatever reason), by the time same customer trying to place another order, "order service" database which was updated based on data from "order management service", which is giving no signal as per business rules. How do you make decision!
(Business rule: until one order either delivered or cancelled, another order cannot be accepted from same user.)
Now, you may make different decision based on who area the stack holder of each service, and how one service trust another service, whether one service has permission to make call to bypass regular work flow. etc.
Exceptional design decision to make security implementation easy for microservice.: if the above “food delivery system” microservices are being developed by an early stage start-up. they can break one design principal “database per service”, instead they can make multiple schemas in one RDBMS, each schema will be for each service, they can set permission for all objects under any schema, so that only permitted schema can access that object.
This approach may help delivering faster and still remain open for future implementation of any event-based communication like RabbitMQ.
Another concern can be how to manage session, understand, no API will be consumed by any end user directly, it will always be through some application, so once user login the user data will be stored in some session variable for repetitive use.
If you are very new to Web API security implementation, then following posts will help you to understand API security implementation better.
Here is another nice post regarding microservice securities best practice, you should look at.