How do you implement "god mode" in your app?
Hey all,
We have a SaaS app built in Node + React + Firebase for authentication. We want to implement a "god mode" where our customer support can log into users accounts with them to help troubleshoot make changes.
Is there a recommended solution to be able to do this?
Trending on Indie Hackers
Is this intended to be a temporary solution while in beta or early access? This strikes me as a security and privacy flaw if left in.
An alternative would be to have a custom dashboard that plugs directly into your database (with limited access) and keeps detailed access records.
This kind of capability (to the best of my understanding based on the OP's responses) is extremely common and called "user impersonation". Many Google products offer it.
It's so that support can see the app as the user sees it, including any bugs which may be occurring based on that user's data. Secrets, such as passwords or credit card information aren't generally shown to users when they're logged in.
Furthermore, the way this kind of system is generally built, it's not quite identical to being logged in as the user. It's more like,
{current_user: "staff1234", impersonating_user: 5678}, so that the admin/support person can experience the app (nearly) the same way as the user would, but also do things like change which user they're impersonating or go back to check support requests, etc.Quite a bit of how it's handed depends on the kind of app. Banking or medical service apps have quite a few issues around this kind of feature. A site like IH where users have no secrets but passwords and everything is public, not so much.
Nope, we want this to be left in for our engineers / support people, with some sort of strict logging / detailed access records to ensure people don't abuse it. Looking for an out of the box solution that does this rather than having to build our own
You are free to do what you like, but for the record, this is a backdoor.
Hmm, I am not trying to create a backdoor do anything shady.. I am just trying to figure out how other support teams do this. I have been on websites where the support people can see my account as if I am seeing it, so would assume its standard practice unless I am missing something?
If it came off as an insinuation, I didn't mean for it to be. I am very wary of this methodology of support, however, and generally take an approach where this would not be possible - it's impossible to be totally trustworthy of those using it and it takes a while to implement it satisfactorily.
There are some things you can do to make this less troublesome - anything that is considered sensitive information, should never be shown again to the user (eg. no viewing of credit card number, passwords, or anything else on their account). Cross details out with XXXs. No regular engineer or support person should need to see these secrets. Designate one person that can if you must, but nobody else.
You want to create a concept of role based acccess control - certain users belong to certain roles, and those roles get extra privileges. These would need to line up with your firebase users. One privilege could be to log in as another user - if you are an admin, you get an extra UI widget to switch to another user. The back end validates that the given user has that privilege, and returns some kind of auth token for the target user. Then the current user can assume the identity of another.
A preferred solution is that proposed by @parhelion, where you create a dashboard that only has the exact capabilities you need to help a user - reset some data field, etc.
To make the god mode strategy work, it's easiest to to assume the identity of another user. But when you do this, it becomes much harder to draw the line of who was doing it.
What you want is ripe for misuse - I wouldn't necessarily use other companies as example in this case.
No worries - honestly this is my first time implementing something like this so just trying to understand best practices. We don't store credit card numbners, hash passwords, etc. Is there a tool you'd recommend we use to implement role based access control?
In your case, I would probably leverage Cloud Firestore and couple it with a Firebase function that triggers when a user signs up - create some kind of extra user record (keyed by uid) says they are of role "user" by default.
When your staff signs up, they will default to "user" that way. Someone with access to firebase can find the uid record, and change to "admin" or whatever you want.
Whenever a user authenticates, cross reference this table to check their role.
So if a staff member that has been granted role admin wants to log in as uid X, verify in the back end they are allowed to, log they requested it, return them some kind of custom auth token for uid X. Now their UI can load the information for uid X and the token they retrieved will allow them to act as uid X for a period of time.
Thank you - I really appreciate this guidance!
Easier said than done, but if you are using Firebase you have the tools to do it - it will require some elbow grease.
One approach is to use JWT tokens for authentication from Firebase (each authenticated request sends the JWT token stored locally). In this scenario we do not use Firebase frontend libraries (our Node app backend performs all Firestore requests and Express is responsible for serving data for our API).
So, we have two pieces of middleware (actually several more, but two for authentication).
The first checks the header for the JWT token, to identify and authenticate the user. This is a normal user session.
The second, checks for an alternative token (a superuser identifier), a field called
impersonate=true, and an impersonation email (the person we're impersonating).The superuser tokens are a very important secret to guard closely. You need to be able to revoke these for specific support users very quickly if you identify any problems, and you should change these at some point (they shouldn't be infinitely long-lasting secrets).
That gets us the ability to make requests as another user. So, our "superadmin" app basically just adds those as query params and redirects to our app (since we don't use any query params in our react app).
Something like
https://our.app/?impersonate=true&tkn=superadmin_token&impersonatedEmail=<end_user_email>Then our middleware picks up on that, and instead of parsing an end-user JWT token, they grab the impersonated user so that all of the downstream requests basically see the exact same thing as if we had passed the end-users JWT token from firebase.
It depends on the auth mechanism you use within your app, and the structure of your users/companies I guess.
In our app we have the concept of multiple users can belong to multiple companies (many to many relationship). It is a trivial matter then for us to connect our own logins to a customer company when we want to provide support for them or investigate/replicate a problem they are experiencing.
However, we have a strict privacy policy in place which requires written permission from the customer each time we do this, because we are dealing in private employee information in our SaaS.
Yep - we definitely want to implement customer permissioning. So you connect your own login to the company as an admin? Is this automated / does a solution do this?
We have a 'god mode' dashboard that our team can access and see all customer companies/activity etc. There is a function within that to attach/detach our own logins to customer companies, then we perform a manual login to that company using our credentials. (each customer company has a unique subdomain URL)
The actual attaching/detaching is done by manually associating user & company records in the SQL database when the button is clicked. That then allows us to get access to that customer company. We detach after the support call, and the customer can always detach us any time they want as well, from within the app.
Wrote a post about this: https://medium.com/@parthi/how-to-build-an-admin-mode-to-impersonate-user-accounts-da4d8092f9c7
Also check out https://helpelf.xyz
I'm wondering if services like https://logrocket.com/ can solve your problem?
"LogRocket lets you replay what users do on your site"
Most cookies have a UserId or something similar ( JWT tokens).
I make it possible for the role admin to override the cookie and use a users Id.
They can easily remove it or change to someone else.
Aka. God Mode
We built similar into our app with a custom solution.
Essentially any of our support staff have list of users with key, aggregated details.
By each account is a login link which will log them in simulating a genuine user from the client system.
But this login is dependent on a support code which can only be controlled by the clients themselves within their own system. They send the support codes via private chat on our support channel (intercom).
Support codes can be disabled or rotated at ease giving the client the control and security they expect, but also enabling high level support where can see and fix issues as they occur.
This approach has worked well for us over the years and we are confident it matches the security expectations we set and uphold. It is not so much god-mode, but more saviour-mode.
Many big companies have something like this, with different security levels...
Most are super custom, when possible limited to a view only user auth, so God mod would be confusing, you normally don't want to let your support actually do anything but view in this mode.
Reusing the lowest view permission in the system reduces complexity most times.
Some verb a user is common naming like immiate a user, login as a user, view as a user...
One of the better security/trust I've seen is default to disabled, needing to be enabled by the actual user. So the support customer asks the user admin to set a permission to allow him to view the account as the user. (It's balanced against the support agent but for the users trust)
I would handle this just with custom rules, and some additional structure to keep admin accounts and their managed accounts ;)
I know this isn't what you want but it's a tried and true temporary solution so you can help people while you figure out your God mode setup. https://www.splashtop.com/
As for God mode, my opinion is that the type of app your building is what determines how much potential scrutiny you will receive. If it's nothing that anyone would ever be skeptical about, then why not so you can save some time for users and your staff. For example, some cheesy game app that doesn't involve any sensitive data or money.
If it's good for you, it should be good for your customer. Do your customers really benefit in order for you to be able to access their accounts? If the benefit is huge and the app isn't a super sensitive service, then it makes sense to implement God mode because every customer will thank you for it. But all the common sense security should be implemented without a doubt so you can never be blamed for fraud when one of your employees starts smoking crack. But if they aren't likely to thank you, then it's probably not a good idea and you can simply use something easy like this https://www.splashtop.com/
I think you should research companies who have the God mode solution you're looking for, which is probably a lot of companies, and then research the original developers using linkedin or something, and then ask them if they built it in-house or if they purchased the system. You can ask them without asking anything too sensitive, just asking if they built it in-house or if they purchased it as a service isn't too invasive.
I don't think it would ever be appropriate to implement god mode in any saas, please never do this.
If all you need to do is to help your customer support quickly troubleshoot an issue for your users, then you may consider using session recordings tool (https://howuku.com) as an option where you can replay all actions of your user and see what actually went wrong with all sensitive information masked out of course.
Being able to impersonate a user in your app has been extremely valuable and is one of the first things I would recommend be implemented if you care about the user experience. For example, often times I will screenshot the screen to provide guidance or help troubleshoot and send that to the customer. Just being able to see what they see and interact with what they interact in real-time eliminates a lot of the guesswork.
Yeah sounds like this is the consensus :)
In EU this would be borderline. Building a god mode implies that maybe too many people have access to sensitive data, and worse can act as a different user. You need then a role based auth as well.
Re your other comment: Only because somebody is a random engineer shouldn't allow him to look up data. Isn't just using directly the DB not enough?
If you need to let your CRM staff make changes, just make a ded restricted view for the CRM people.
Firebase Auth do not support this out of the box. You can implement it using custom token generation https://firebase.google.com/docs/auth/admin/create-custom-tokens
Hmm, this is not quite what we're looking for. When we have people in our app reach out to us for support (e.g., through Drift), I want to be able to quickly log in to the app and see their exact session (or maybe control their screen), so that I can fix things / try things to see what the problem is.
Than you have to do your own session management using session vookies https://firebase.google.com/docs/auth/admin/manage-cookies
And you have to implement the mechanism which issues, store and provide this cookie to 3rd party (your god user). I’m not sure however that if you directly write to firestore from your frontend app that would help. User impersonation violates the OICD protocol so even Auth0 dedicated that feature they had.