Feature Request: User Impersonation

[TruDan]

It would be really useful if admins have the ability to "login as user X" to temporarily override their session with a different user.

For example in our app, if a user reports a bug, we could log in as them in order to reproduce the bug and debug it further. Without the need of having their password.

Is this possible?

Related

• Implement Impersonation and Delegation Tokens (RFC8693) #1471
• [Category] OpenID Connect #2324

[mooreds]

See this forum post as well: https://fusionauth.io/community/forum/topic/71/does-fusionauth-have-an-impersonation-feature

[robotdan]

Are you looking for this feature particularly for use in the FusionAuth admin UI?

[TruDan]

Are you looking for this feature particularly for use in the FusionAuth admin UI?

For our use case it can either be in the admin ui or as an api call/URL to redirect to. We use jwt to authenticate requests to our api from a frontend react app, I'm not sure how to implement it in such a way that isn't hacky/doesn't compromise security

[voidmain]

It sounds like what you need is a way to generate a JWT for any user as long as the user that is impersonating another user is an administrator. We don't have an API for this currently but I can think of one way to accomplish that using our APIs:

1. Create an API in your backend to allow an admin to impersonate another user by id (or something like that). Maybe at /api/impersonate/{id} or something.
2. This API verifies the current user's JWT to ensure they are an admin
3. Your backend calls FusionAuth and updates the registration for the user to be impersonated. The registration should be for the application the admin wants to impersonate them on. You'll call this API to update their registration: https://fusionauth.io/docs/v1/tech/apis/registrations#update-a-user-registration and you will need to specify generateAuthenticationToken=true. This will add an authentication token to the user's registration.
4. Finally, your backend then calls the Login API and sends in the user that is being impersonated's loginId and the authentication token as the password.

This will return a new JWT for that user. You'll then have to store that JWT somewhere special so that your React app and backend both know this is an impersonation process. You could store it in a special cookie or something like that.

[pendenga]

@voidmain would the strategy you describe allow the Authentication Token to be used in the OpenID Connect workflow, or only in the API?

[voidmain]

Hi @pendenga - sorry for the delay on this. Busy times right now.

The solution I outlined would only work at the API level.

Allowing impersonation via the OAuth/OIDC workflow could be a large security issue and as far as I know, it would break the specification quite heavily. I'd have to really think about that one to see if it is even possible.

Using my solution above, this feature would live inside your application's admin UI with a button that allows an admin to "Become User". This button would leverage the API I outlined above to create the second JWT. Then your application would ensure that the impersonating JWT is used when needed and the admin JWT is used when needed. That portion would be completely application specific, so FusionAuth would not be involved in that at all.

Let me know your thoughts on that.

[mooreds]

Here's an RFC that could be used for both impersonation and delegation: https://datatracker.ietf.org/doc/html/rfc8693 and here's another related link: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow

[mooreds]

If using the API, you can also retrieve a user's JWT via the passwordless flow: https://fusionauth.io/docs/v1/tech/apis/passwordless/#start-passwordless-login

[awoodobvio]

Also got here while building out our microservice approach.

User Z -> API Gateway verifies access token --> Service A --> Service B

In this case, Service A wants to call Service B "on behalf of" User Z (delegation)
This is covered with the "urn:ietf:params:oauth:grant-type:token-exchange" grant type defined in rfc8693 (linked to above).

Are there any plans to support RFC8693?

[mooreds]

@awoodsprim I do not believe this is on our roadmap, but seems like a great enhancement.

Can you please file a separate github issue because implementing this standard is slightly different than the generic impersonation feature? (Feel free to reference your comment.)

Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap/