Creating a Consent-Based User Account Access System

Consider this scenario, you’re sipping coffee on an evening (Tea if you like that more), coding away on the next big feature of your app and suddenly there’s a ping. A user is having problems with your app and no one is able to figure out the root cause and they need you to come in as the big gun.

You put on your debugger hat, close the VS Code window that you were coding away on and hop on to debug the problem.

After some time the one statement that a developer dreads inevitably comes out of your mouth “Ah! I wish I had access to the user’s account.” born from the evergreen “The issue is not reproducible on my system.”, and you ask the support team if there was a possibility to get access to the user’s account.

Now, if you’re in a startup getting access to a user’s account is super easy to do, you would probably have access to the auth system yourself so you can generate the tokens you need to access the user’s account, debug the problem and expire the token. But at slightly larger companies where you have support teams and most issues can be solved without any engineering intervention via simple access to a user’s account, it’s invaluable to have a system like that in place.

Having backdoor access to a user’s account is something users are very uncomfortable with and rightly so, hence there are policies in place that prevent developers and support teams from accessing a user’s account without prior consent.

In this post, we’ll be building a system to gain access to a user’s account with their consent, and have the sessions be limited to the time the end user allows for debugging issues they face.

Even if you’re a startup, it makes sense to have a system like this in place for compliance, holding people accountable and promoting responsible debugging; all while ensuring that once you scale up to the size where a support team is required, it is equipped to solve any end user issues.

Many companies use this kind of system to provide support to their users including Notion and Salesforce, so you’re in good company if you decide to implement this.

The Flow

Technical Implementation Flow

Implementation Specifics

We won’t be going into code for the implementation of the above flow, simply because there are many authentication systems in the wild and if you have worked on the authentication of your app, you would know what you need to do in order to implement the flow.

The implementation of this flow does however make a few assumptions: It requires you to have a backend set up that has access to your authentication layer (If you’re using a service like Firebase, then Firebase Authentication provides Firebase Admin SDK with super-user capabilities on the server).

This flow works ideally with JWTs because they have expiration built into them.

Some considerations

With this feature there are obviously some things you would have to consider:

• The support team should be 100% trustworthy since you’re giving them access to your user’s account.
• Support teams should not have access to the database to toggle the setting to let them in and out of a user’s account anytime.
• Anyone handling the database and backend (Ex: The administrator) can obviously access the user’s account but that’s a given with super-users.
• Make sure to know the legal requirements of implementing such a system for the domain your application operates in. Most of the time, in industries like Finance and Banking, this is not even allowed.
• Make sure you’re keeping a log of the user’s consent, token usage and expiration to hold stakeholders accountable.