...
- Get Auth Token Internal communication can be authenticated in two ways, if one service wants something from another service on behalf of a user request, it can use the access token from the user to authenticate against another microservice. This is the preferred way of authenticating interservice requests, as users permissions are automatically applied everywhere in the service chain. However, sometimes it is impossible to provide a user token such as in cron-executed requests, which is why the service registry provides auth token for internal services. A service can get one of those tokens by supplying the api-key to the registry as a proof of authenticity. The api-key which is generated by the registry sits in a shared docker volume and thus is accessible to all microservices. This request to get the auth token can happen at the startup of the service and is not necessarily a part of the communication chain, however it has to happen before the rest of this communication which is why it is shown here.
- Query for service in category The registry holds servicenames by categories, so when a service needs information about users, it can query the registry for a service which serves that category. For performance this response can be performed at the startup of the service and cached for the whole lifetime of the application, as this is not going to change often and currently changes would involve a restart of the whole system anyways.
- Name resolution The result of the registry query is a url which the service can use to query other microservices. This url is either a Traefik frontend rule which is directly proxied to the instance or an internal domain name, which can be resolved by the swarm dns as we already saw it in the db request from the core in the above scenario. This part is pretty obvious and it is just included to raise your awareness of the two ways of resolving a name to another service inside the setup, but most of the time you will not have to care about this, as the registry currently only returns swarm-dns names and even if it wouldn't, the microservices won't have to change any code to reflect that.
- Query The actual query for data from the other service
- Validate token In case the other service used an auth token supplied by the registry, the other service has to validate that token against the registry. In case it was a user token, the usual authentication method can be used .(Currently this is done only in the core by means of middleware)
- Response On successful validation the queried service will return the requested data to the requesting service. Note that token supplied by the registry automatically mean high access rights, as many requests will be open without limitations to other services, so it is vital to protect those auth tokens inside the services.