My company has its own proprietary software that I have both built and maintained over the last 5 years

I am about to release a big change for all of my software to use OAuth2 instead of handling emails and passwords ourselves. Prior to this release because I managed 100% of the dataflow, I had a feature for the admins that they could generate user token to impersonate the user - this was especially useful for troubleshooting while in production.

My question is, what is the business standard for a developer who does not provide software for the open market, but supports private users for one company? Without the feature we had I am reduced to troubleshooting via screen-share with the end user themselves.

Would it be bad practice for me to implement a similar feature to what I had before? What do other companies do?

  • Just FYI: GitLab provides impersonation as a standard feature, but has a very strong audit trail built around it. They also have multiple SSO options. – Jan Dorniak Mar 2 at 18:29

There is no standard which is used by every company: some rely on impersonation; others avoid it at all costs.

Impersonation was useful fifteen years ago, where there weren't many convenient tools for screen sharing. Today, not only there are plenty of tools for that, but most users are familiar with at least one of those tools. Moreover, more often than not, troubleshooting requires the user to show exactly what he did: just logging in as this user often isn't particularly helpful. If for your product it is, it might indicate some design flaws in your product, or the lack of proper testing.

Note that impersonation presents a series of concerns in terms of security, privacy, and audit. As soon as someone can login as somebody else, it becomes very difficult to prove that a hacker (or a disgruntled employee) cannot do that. Similarly, a disgruntled employee can use impersonation to grab personal information of your users, which could be very problematic, including legally.

A concrete example: when I login from a new device to my GMail account:

  • I receive an email about that,
  • I get an immediate notification as well on my mobile devices,
  • If I'm already logged in on an old device, I see the message that I'm also logged from a given device.

Those are all the very concrete steps Google does to protect my account. Now, if some employees can access my emails by impersonating me, they would have to remove all those security features, because they become useless: I would have no way to know if my account was hacked, or if a Google employee was accessing it.

  • What about for provisioning new users in order to verify their permissions? A second portion of what we have used it for is to verify the user experience when provisioning new features. – alilland Feb 12 at 21:54
  • A second portion of what we have used it for is to verify the user experience when provisioning new features. After adding oAuth2 im going to have to manually curate my own developer account with every end users roles in mind - or as you said write tests for every scenario. With myself being the developer for years of code thats been written largely without any UI tests 100% code coverage just isn't feasible.... we write backend tests but have found frontend testing to be a beast. – alilland Feb 12 at 22:01
  • @alilland: not sure to understand what you mean by “to verify their permissions.” Permissions should be binary: either a user has them, or not. There is nothing to verify (and if you actually have to verity, then there is something very, very wrong with the permissions system). As for the lack of UI tests, you can have special test accounts with different roles, and use those accounts to perform your manual tests of the UI. – Arseni Mourzenko Feb 12 at 22:24
  • 1
    Jivan, Google could create software that allows them to do illegal things, but that doesn’t mean they have created this software and can do these illegal things right now. – gnasher729 Feb 13 at 11:30
  • 2
    Screensharing is a great tool for lots of cases, but when developers work at completely different times as lots of the users, or want to reproduce a certain bug scenario at a point in time when the user who filed the ticket is not available, this may not a be a sensible alternative to impersonation. – Doc Brown Feb 13 at 18:50

Whether you own the company or not, I think the only clean way is the ability to change someone’s password, in a way that is clearly and undeletably logged. If you can log in as an arbitrary user without a trace, then any user can deny any wrongdoing because you could have done it without leaving evidence.

And then there is of course 2FA. For some things, you would need my phone. Which you don’t have because it is in my pocket.

One scenario that you describe is absolutely fine: You get a new employee, you set up an account for them with a password you know, you check whether their permissions have been set up correctly for them (the new employee will have no idea yet what permissions are right) and once everything is right the new employee changes the password, sets up 2FA and so on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.