There is a lot of data flow between services in a microservice architecture. Making that data tamper proof is another challenge; how calling service ensures that data received by it, is not tampered with in between communications. Also, there should be some identifier to know which data is sensitive, hence extra care needs to be taken; for example in cases of payment data.

We just hit the tip of the iceberg. There are many challenges faced in the security of the microservice. The API Gateway can also be a solution to some of these threats. Fortunately, we have some standard practices that can be followed and assist us with the basics of security.

There are some common practices for security that should be considered in microservice architecture:

• The basic thing is to use certificates during communication, even HTTPS will be a good start here (if communication is REST based).
• Encrypt traffic among services communication.
• Make the correct access strategy. Access between components should be restricted. It should be started with the lowest permission and given only the required permission.
• Monitoring is another tool to deal with the security aspect. If good monitoring is in place, it can give you a good view of what's happening in the system.
• Log all the things required to debug or identify any security issues. It will be helpful for the developer's team as well.
• Test your security infrastructure on regular basis.
• If any third-party code or container is used in your microservice release, you should verify or scan that completely before using. Using this kind of stuffmeans you need to keep eyes on any security patch updates.
• Open Web Application Security Project (OWASP) has some very nice tips and cheat sheets for security. These should be considered while thinking in terms of security.
• Code review should be done very frequently and with less lines of code. If you ask someone to do a code review of more than 1000 lines, you will hardly get any comments. In contrast, if you share less than 100 lines of code, you will get more comments.

Normally, a token-based system security is adapted from the security designed in the microservice architecture. Its strategy is not only for REST-based requests, but can be used in other formats also. The concept is based on the idea that the client gets the token first and embeds that token in each subsequent request. This token will be issued to the client after authentication and authorization from the authentication service. The resource owner will verify this token with the token generation server and check whether this token is valid to serve this request. It will work this way until the token expires. Once the token is expired, then the client has to provide its credential to the token provider again and get the new token. JWT is the most commonly used format for REST-based microservices. JWT goes one step ahead and adds the scope and action permit to the client in the token and seals it with encryption algorithm. The next section discusses this authentication and authorization framework and JWT tokens in detail.