I am confused - what is best way to pass user identity (authorization information) between microservices in asynchronous way?
Lets say I already have entry point (api gateway) that handes authentication and issues JWT tokens. Then user calls some API endpoint with this token. Up to this point everything is clear. Now - this endpoint needs to communicate with another microservice. That microservice must get authorization information (roles, etc). Also - this channel is asynchronous (JMS/Kafka), which means processing might be dalayed...
I was also thinking about other case: we have two services A and B. both expose API that might be accessed by external user (JWT token auth), but they also need to cooperate asynchronously (by JMS). They both need user identity context. Again - how to pass it?
I can:
all of them have cons for me and I cannot find universal solution...
--Edit
Consider case: there is product catalog service and ordering service. Both expose public API. User places order, it is queued for processing. First step is to verify if products are ok and user was allowed to order them. Processing may call product catalog service but has to pass user context. This is the part that I am talking about.
To perform authentication based on entity context, you must receive information about the end-user and propagate it to downstream microservices. A simple way to achieve this is to take an Access Token received at the edge and transfer it to individual microservices.
The synchronous call is the simplest way to communicate two services. It also bonds them together, since the calling microservice needs to wait for a response from remote. This kind of coupling can sometimes be prevented by using asynchronous communication.
The most common type is single-receiver communication with a synchronous protocol like HTTP/HTTPS when invoking a regular Web API HTTP service. Microservices also typically use messaging protocols for asynchronous communication between microservices.
You have
In the second case, MS2 is acting on behalf of the user and therefore JWT of the user makes sense here.
In the first case, Kafka Consumer is just syncing the actions that has already taken place in MS1. It is not acting on behalf of the external user. The external user doesn't have any control here. The user cannot read or write anything wrong at this stage. User interaction ends in MS1 itself.
Therefore, the external user JWT is not required in the Kafka Consumer for authorization purpose. However, in the message you may pass the user context like username and other relevant details for processing. Based on these information, you need to decide whether you would go ahead with the order or not.
Kafka consumer will, however, need it's own access tokens that will be used across all different user orders. The OAuth 2.0 grant type you need to use here for the communications between the Kafka consumer and MS2 is called "Client Credential" grant type.
Here, the Consumer will directly contact with the Authorization server with appropriate credentials and client id to get an access token
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With