DEV Community

Vishesh
Vishesh

Posted on

Communication within microservices

Intro

Every microservice has its own bounded context and will not have data is not within it's domain. Lets assume, we have a ecommerce system with below microservices:

  • User microservice - Includes APIs to login, log out and user profile
  • Product microservice - Include APIs to list, add, edit or delete products
  • Billing microservice - Include APIs to generate bill and initiate delivery.

Why we need to communicate?

If we observe closely, for billing microservice, to generate a bill it will need product price and details. Hence the billing microservice will need to communicate with product microservice and get the full product details.

How to communicate?

Simple, call the list API in product microservice from billing microservice. Yes, this should be fine and we are not violating the bounded context by accessing product details directly from DB.

But ...

But we have to authenticate right? Generally frontend will use the user login token to authenticate. But how can a microservice get this token? It will not have the user login details. Moreover, this is user token and is meant to be used for APIs that a end user can access. So, its not a good practice to use this token to communicate between microservices.

Solution

Hence we will need a specific token to authenticate communication between microservices. Token can be anything:

  • JWT token
  • Firebase token
  • Custom token generation logic

We must ensure to follow below process to ensure the communication is secure,

Solution 1

Image description

  • In the authentication mechanism for all APIs introduce a new API header like "X-MS-TOKEN". When ever this is passed decrypt and verify this token.
  • In the billing microservice when calling product microservice for details. Encrypt and attach the token in the "X_MS_TOKEN" API header This is a very simple way. But this has a security concern that if this token is leaked then anyone can easily access the API. We are not refreshing this token at all. This could be a concern when dealing with APIs that involve billing. Anyone could easily generate multiple bills.

For more security

  • Use a third part service like firebase or create your own token generation service and fetch a token every time you call API to get details from other microservice. This way the token remain fresh each time and even if its leaked it not relevant for single use.

Latest comments (0)