Authdog
Log In

Identity guide

User Management

The same person in two environments is two users.

Confirm you are in the right environment, then create, import, suspend, or revoke. This guide is the console path, and the checks that tell you the change actually took.

Prerequisites

  • The Authdog project, with the environment you mean to edit already selected.
  • Console access limited to the people who do support or administration.
  • An organization and role model, if these are B2B users. You need to know where access comes from before you remove it.
  • A way to verify someone's identity that does not depend on the factor you are about to reset.
  • A test user you can sign in, suspend, revoke, and reactivate without paging a customer.

Implementation

1. Pick how this user should be born

Self-service sign-up, social OAuth, enterprise SAML or OIDC (the account appears on first sign-in), SCIM or another HRIS feed, or a console import when you are migrating. Authdog links multiple identities to one user only when they share a verified email. An unverified address must not merge two people. If you are tempted to "just match on email," stop and check the verified flag first.

2. Read the user before you change them

Open Users in the environment you confirmed, search, and read profile, active state, groups, recent activity, and sessions. Before you remove access, name where it came from: a direct assignment, an organization membership, or a group mapped from the IdP. If SCIM or the IdP owns the field, a change you make here will be overwritten on the next sync. Change it upstream instead.

3. Import a migration in a small batch

The console accepts CSV, XLSX, and XLS up to 10 MB. Auth0 and Firebase templates are available if that is where you are coming from. Every row needs an email or a username. Read the preview counts for valid, invalid, and warning rows, and do not confirm a file you have not read. Never import a plaintext password. Supported hashes are bcrypt, scrypt, argon2, PBKDF2, and SHA-256 or SHA-512. Run a handful of rows, sign in as one of them, then import the rest.

4. Suspend when you need them gone and the history kept

Suspend for offboarding, for a compromise, or whenever you must block access without deleting the record. After you suspend, try a new sign-in and try an existing session against a protected route. Both should fail. If SCIM owns this user, make the lifecycle change in the directory. Reactivating them locally will fight the next sync, and the sync will win.

5. Revoke the session when the device is the problem

Open the user's sessions and read status, expiry, and device. Revoke the one that is lost or suspicious. That user should have to sign in again. If you think the account itself is compromised, revoke, suspend, and reset MFA, in that order, after you have verified the person through a channel that was not just stolen with the laptop.

6. Let people fix their own profile, and keep admin actions rare

The hosted Account Portal covers profile, credentials, connected accounts, and the user's own sessions, without a redeploy. Leave it on for that. Keep MFA reset and suspension in the console, and verify the person outside the factor you are disabling. A "disable my MFA" request that arrives only through the account you are unlocking is not verification.

Security considerations

  • Read tenant, project, environment, and the user record before any destructive action. The costly mistakes are the ones performed in the neighboring environment.
  • Link identities on verified email only.
  • Keep imported hashes and personal data out of logs and tickets.
  • Suspend when you must keep history. Delete when you are done with the record. They are not the same button.
  • The console can show a role. Your API still has to enforce it.

Validation checklist

  • Operator selected the intended environment.
  • Verified-email linking avoids a duplicate identity.
  • Imported test batch reports reviewed success and failure counts.
  • No plaintext password was accepted or retained.
  • Suspension blocks new access while preserving the user record.
  • Session revocation forces reauthentication.
  • User can complete approved Account Portal self-service tasks.

Troubleshooting

You see two users for one person. Compare the provider identities and whether the email was verified on both. Unverified email does not link them, and it should not. Verify, then look again, or keep them separate.

A profile edit comes back. SSO, SCIM, or the HRIS owns that field. Change it there. The next sync will keep restoring the upstream value.

A suspended user still shows up in search. That is the point of suspend. The record and the history stay. Sign-in is what should fail. Search them, confirm the suspended state, and try the sign-in.

Next steps