How do I impersonate a user in M2M communication

Help
1

We have a microservices environment. Identity is provided to http microservices via bearer tokens in the authorisation http header, where the token is a JWT. That JWT usually represents a logged in end user, but it can also sometimes represent a system user that has authenticated via client credentials flow.

Messages are published on a queue (RabbitMQ) by these microservices, to be processed asynchronously. Currently, we have a windows service which consumes those messages. It authenticates as a system user with client credentials, and sends that JWT in the auth header to other http microservices.

We would like to maintain the identity of the user that publishes the messages throughout the flow, including within the machine-to-machine (m2m) communication when a message is consumed from the queue and when that consumer calls other microservices. Ie, when Service A (which was provided with a JWT) publishes a message to the queue, then the windows service should be able to impersonate the user represented in Service A’s JWT, and should be able to provide a JWT representing that same user when calling Service B.

Service A (running as alice) --> RMQ 
RMQ <-- Win Service (running as alice) --> Service B (running as alice)

Only clients with the correct claim should be able to impersonate a user in this way.

Which flow should I use in order to return the JWT to the Windows Service and how should this be achieved in Auth0?

Note that the original JWT can be provided with the message, or just the user id itself. The original JWT may have expired, which is why the windows service has to re-authenticate in some way. The original user authenticated via Implicit flow (we have an SPA), so refresh tokens are not available.

1 Like
2

Hi @dim,

Welcome to the Community!

I’m afraid I don’t have an answer for you … just responding to get this to the top of the pile. Possibly @jmangelo or @john.gateley might be able to provide some feedback on this one.

3

@markd, @dim

I am hesitant to comment on this. Any time “impersonation” comes up, I worry about security. Any solution you come up with deserves a full security analysis here, to make sure you are not opening up attack vectors.

Having said that, and so taking this with a HUGE grain of salt: I would suggest making the identity of the requesting user part of the arguments to the API call, not implicit in a JWT used for authn/z. Keep the boundaries clear, this will make security and logging and everything else much easier. It is more clear to say “Service A is requesting this action, and “Alice” is one of the arguments to the action” than to say “Service A is requesting this action on behalf of a user Alice”.

I hope this helps, and as always with complex cases such as this, I recommend Auth0’s professional services.

John

1 Like
4

@john.gateley, @markd

Thanks John. That’s an interesting idea. How would you then approach authorization in Service B? The current principle (the m2m user) will have permission to read:messages, and this can be checked very easily against the m2m jwt using the framework (we run in a .Net environment). Is there any best practice for authorizing an endpoint for a user id that has been provided as a parameter?

-Dimitri.