How to secure messaging-based communication with microservices

Question

I'm comfortable with a lot of OpenID Connect and OAuth2 concepts in the context of HTTP-based communication between microservices. I'm currently leveraging Azure AD.

In the HTTP-based scenario I would typically use the on-behalf-of flow for communication between microservices where I need to maintain the user identity in the access token.

My question is what is a good approach for handling this when using queues (e.g., service bus) and the service processing the message from the queue needs to call another microservice to collect information. In my case the microservice being called can do fairly complex authorization based on the context of the request and the user.

I'm aware that I could essentially do service-to-service calls and let the microservice processing the queued message enforce authorization, but I don't want to duplicate that logic in the calling service as well.

If I tried to include the access token in the message or some similar approach, then I would be at risk of it being expired by the time the message was processed.

Answer 1

In most cases messages are processed so quickly through the queues that its really no different from.a synchronous operation.

If you are concerned you can always configure the downstream services to ignore the expirey date, or extend its validity.

However. I would draw a line somewhere in your stack and say "at this point I accept or deny the request" after that point you no longer use the auth token.

The command has been accepted and will be processed by workers running as service users that have the required permissions. How its implemented and how long it will take are unimportant.

In this way you explicity call out the point where you can still revoke the users permissions. It makes it eaiser to be sure about your risks and edge cases.