Microservice calls service, authorization from a queue message

Question

Context: I am creating a cloud platform to support multiple applications using single sign-on. I use Keycloak for authentication and Netflix Zuul for authorization (API Gateway) through the Keycloak Spring Security Adapter .

Each microservice expects an authorization header that contains a valid JWT from which it will process the request (sub). Each microservice-microservice call must first go through Netflix Zuul, passing an authorization header in order to support a non-persistent state check. This strategy allows each microservice to know who the user is (sub) who indirectly calls the microservice.

Problem / Question 1: What happens if the microservice is called from a queue message? One of the ideas I had was to queue up the information associated with the + userInfo message and create specialized microservice processing to process such messages. With this approach, this special microservice should read userInfo from the queue and process the message.

UPDATE 1: for sending an email from another forum, keeping the JWT in the queue is not a good idea, as it can be easily started.

Problem / Question 2: But what happens if the previous special microservice wants to name another normal microservice that expects to receive JWT in the header? Should this special microservice be created by JWT itself to impersonate the user and be able to name ordinary microservices?

Another solution that I thought was to keep the original JWT in the queue, but what happens if the queue calls a special microservice again? Immediately after the JWT is already invalid (expired), and the called microservice will reject the request?

Possible solutions: (Updated by João Angelo, see below.)

I have to authenticate requests from my users ( authorization code stream ) and my services ( Client credentials ), both requests must contain user information in the payload. When the request comes from the user, I need to check if the user information of the payload meets the requirements of the JWT. When a request comes from a service, I just need to trust this service (while it is under my control).

I really appreciate your help. Thanks.

Answer 1

Disclaimer I have never used Keycloak, but the wiki index says it is OAuth2 compatible, so I will trust this information.

---

At the highest level of vision, you have two requirements:

• Authenticate actions initiated by the end user when using your system.
• Authenticate actions initiated by your system at an unknown time, and where there is no need for the end user to be online.

You already met the first one, relying on an authentication system on tokens, and I would have done the same for the second point, the only difference would be that the tokens would be issued to your system using the OAuth2 client credentials instead of other grants intended for scenarios where there is an end user.

(source: Grant Client Credentials )

In your case, Keycloak will play the role of Auth0, and your client applications are microservices that can support client secrets used to authenticate with the authorization server and receive access tokens.

Keep in mind that if your system relies on the sub application much more than on authentication and authorization, you may need to make some changes . For example, I saw systems running action A necessary to know that it was intended for users X and Y, but the payload for action only for user Y and intended user X was the current authenticated director. This works great when everything is synchronous, but just by switching the payload to indicate that both users mean that the action can be performed asynchronously using an authenticated system.

Answer 2

One of the common settings is the presence of an API gateway that checks all incoming requests with its JWT. The API gateway verifies the JWT signature (or decrypts it for encrypted JWTs), checks expiration times, etc. And it extracts the areas and user identifier (sub) from it.

Then it compares the areas with a set of specific areas for each micrto service, and if the area gives the user (subject) access, the request is sent to the microservice. The user ID (sub in the JWT) along with other necessary information stored in the JWT is placed in the headers of user requests, such as X-IGNACIO-SUBJECT