Impersonation

Sign in as a user to see what they see while you help them. Every impersonation is recorded, and apps can tell when a session is impersonated.

Permission

Turning impersonation on needs Change sign-in, branding, domains and keys. Impersonating needs Impersonate people, which the Owner, Admin and Support roles have.

Turn on impersonation

Impersonation is off for new organizations. To turn it on, open Settings > General and switch on Allow impersonation under Support.

Turning it off again ends every impersonation in progress.

Impersonate a user

1. Open the user's page in the console.
2. Choose Impersonate.

A new tab opens on your organization's URL, signed in as the user, on their apps page. A banner names you and the user, with an End impersonation button.

You can't impersonate users who are disabled or who haven't accepted their invitation yet.

Warning

If you're already signed in to your organization's URL in the same browser, impersonating replaces that session.

What you can do

You can do anything the user can, except actions that need their own password or passkey:

Action	While impersonating
Open their apps	Works
Change their name or picture, sign out their other devices	Works, if users can do it themselves
SSH with Access, and request access	Works. Fob records you alongside the user, and you can't approve a request you made as them.
Change their email, password, passkeys or authenticator app, or delete their account	Needs the user's own credentials
Open a terminal in the browser	Needs the user's own credentials

The audit log names you, not the user, for every change you make.

When an impersonation ends

An impersonation ends when:

• you choose End impersonation or sign out
• 30 minutes have passed, or 10 minutes with no activity
• the user is signed out everywhere or disabled
• impersonation is turned off for the organization
• you lose the Impersonate people permission or leave the organization

Detect impersonation in your app

Use this to block actions a helper shouldn't take on someone's behalf, such as approving expenses or deleting data.

Tokens issued during an impersonation carry an act claim that names the admin:

{
  "iss": "https://acme.fobauth.com",
  "sub": "0193a4f2-7c1e-7b3a-9f0e-2d4c5b6a7e8f",
  "aud": "fob_8c1d2e3f4a5b6c7d8e9f0a1b",
  "act": {
    "sub": "0192ff10-3b4d-7e21-8c90-5a6b7c8d9e0f",
    "email": "grace@acme.com"
  }
}

Check for it in your app or API:

if (payload.act) {
  return res.status(403).json({ error: "Not allowed while impersonating." });
}

act is in both the ID token and the access token, but not in userinfo or introspection responses. See Scopes and claims.

SAML apps get a fob_impersonator attribute with the admin's email instead. See SAML apps.

Apps don't get a refresh token during an impersonation. When the access token expires after 15 minutes, the app sends the user through sign-in again, which uses the impersonated session while it lasts.

Auditing

Each impersonation appears as:

• user.impersonation_started and user.impersonation_ended in the audit log and as webhook events
• a sign-in with the method impersonation by grace@acme.com in the user's sign-in history
• entries on the user's History tab in the console