Passing user identity and authorization between microservices

6
votes

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:

  1. pass JWT token along with queue message - is it safe? what if tokens expires before target service starts processing?
  2. convert information from JWT token and pass it as HTTP headers - what if target service returns information - I need to regain authorization context from that response (it must be still processed in context of specific user), but this makes me handle two types of authorization: JWT and the one returned from asynch process...
  3. ...?

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.

1
oauthauthorizationjwtmicroservices
why You need to pass jwt when you are pushing it via queue?. the queue is already accessible by only Authorized clients and you can simply pass messages between. the purpose of queue is to keep messages long as it required to make loosely coupled microservices. However to access the api via http you must pass authorization header. - Imran Arshad
I want to pass authorization information. User is authenticated, that is true, but I also need his roles, tenant context, etc... - redguy
I also want ability to call subsequent services, so passing jwt would solve that also... - redguy
If you really want to send the Jwt token then increase the expiry time (couple of mins is ok). it should withstand queue unavailability. Passing token is fine as long as its properly secured and it's already flowing through the secured queue channel . - Imran Arshad

1 Answers

4
votes

You have

  1. Gateway -> MS1 -> Kafka -> Kafka Consumer -> MS2
  2. Gateway -> MS2

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