How to implement Account / User Impersonation in ORY Hydra

ORY Hydra
#1

Hi there

Our application has a front-end for regular customers, who authenticate by providing an email address and password. We have successfully integrated Hydra and Oathkeeper into our stack to handle this (using authorization code flow), and have been very happy with the results.

We also have an Admin Portal, whereby Support Agents (who are authenticated via Active Directory) are able to look up customer profiles, and then ‘become’ them (effectively signing into the main site as that customer).

My question is: how would one implement that a Hydra Access + ID Token would be issued for these Support Agents masquerading as customers, when there is only 1 configurable Login + Consent endpoint in Hydra?

Should we implement different behaviour when encountering the request coming from the Admin Portal Client ID, or is it possible to run 2 separate Hydra instances (each configured with a different Login + Consent handler) but share the database + secrets to ensure that tokens issued by one Hydra are interchangeable with tokens from another?

Thank you.

#2

First of all, congratulations :slight_smile:

What you describe here is impersonation, so basically what you want is that your support staff impersonates a user. This may be helpful in scenarios such as service desk / help desk.

This is not natively implemented in ORY Hydra as it has many security implications and can easily be misused.

The best way to implement account impersonation on top of OAuth2 is probably to add a custom claim to your Access and/or ID Token called e.g. impersonating_subject which contains the ID of the subject you impersonate.

This allows you to:

  1. Trace who impersonated the user
  2. What actions the impersonator performed in the user’s account
  3. Keep a logical separation between impersonated and “normal” sessions.

While this is a bit of extra work (you have to identify and handle impersonateing_subject) it allows you to easily distinguish between these two use cases. If you want, you could also use impersonating_subject in ORY Oathkeeper’s ID Token Mutator to make it the subject field. But this would then make it quite difficult to trace who did what when and where.

So, as so often in software, this depends on your use case and context and security considerations. But generally, this is the way to go in my opinion!