Is there a way to use OpenIdConnect flows to implement "login as" functionality

Question

We have an application which uses OpenIdConnect to authn/authz access to the system. We use our own iDP based on .NET core library: openiddict. We have 2 tiers of access to the system.

• A set of users called root users
• Rest of users who belong to a particular tenant

Tenant specific users can only access what belongs to their tenant. (Clients to our product) Root users can view/manage across tenants (usually employees of our org) and have a different view of the application.

The problem we are trying to solve is the idea of remote access, whereby the root user gets to act as if he/she is a member of one of the tenants. This enables them to see what the end user sees and help troubleshoot issues.

In this, an authenticated root user would essentially go to a tenant list screen, click a button "Login as user in this tenant", this would cause the page to refresh, his access to be temporarily downgraded to that of a user of that particular tenant until he logs out of this session.

In our legacy system using username password based authentication, this was handled directly by just modifying his session cookie directly to demote his access We want to know if this feature can be reliably implemented using OpenIdConnect and steps to ensure that it can be done securely.

Answer 1

This is impersonation, so you are not really logging in as someone else, and you also won't want lots of separate credentials for the root user.

The usual technique is to invoke a custom screen after a root user authenticates, to see if they want to impersonate someone. Then claims such as sub and act_as in access tokens are updated.

A couple of recent articles from Curity explore this topic and the related standards. It is one of many areas where you need good extensibility in the Authorization Server, since OAuth is meant to provide toolbox features such as this, to simplify your code.

• Impersonation Approaches
• Impersonation Tutorial

For systems without these capabilities it can get a bit messy, since you may end up with custom screens in your own apps, along with secondary cookies, plus changing your API authorization.