With the many evolutions of the internet over the past years, the appearance of the cloud, and mobile applications to make our private and professional life easier, the question of simplifying and unifying all our services came up. And it is with these novelties that different technologies, protocols, and paradigms have appeared.
The idea of the microservices approach is to segment each part of the software into different services that are independent of each other in terms of their functional scope.
Each service is: small, designed to perform a single function, resilient, and minimalist but complete on the task it has to perform. This makes each service independent of the others, simple to replace, simple to update, and therefore facilitates the deployment.
It allows a software, process, or application (the consumer) to use the secure API of another software (the provider) on behalf of a user. It is based on a token exchange mechanism that has the advantage of not trusting the client machine.
Because the client machine could be not secured and even of being able to sign the token in order to be able to verify its origin afterward.
Users are assigned a role by the authority server that allows them to access a resource or not. The RBAC allows one to associate the same role with several users who must be able to access the same resource. It is, therefore, an ideal system for companies with a consequent turnover that will be able to simply assign a role to the incoming user without modifying the access controls.
We can therefore see in these examples that the same thing always happens regardless of the service called. The difference is that if the role is not suitable for the service, it rejects the call without even contacting the database.
It's quite simple, a JSON web token is a character string in three parts separated by dots. Each part is encoded in base 64 and once decoded we can find :
The header allows us to know the algorithm of the signature for the third part and the type of token, which is JWT.
The payload contains the data on the user who uses it as name, first name, email, identifier, role, the date of realization of the token, and the date of the expiration of the token...
This part can contain any useful field without limit.
Finally, the last part is the signature of the two first parts, it allows for validation that the token is valid or not.
So to conclude, we can see here that each service has the power to say which role it accepts for a given action. That can thus make it possible to create, update and remove an infinity of services but also an infinity of users without the one depending on the other. It is therefore very interesting in the case of companies with a high turnover and/or in the case of using software that is destined to evolve very regularly.