Authdog

Identity guide

User Management

Authdog stores users per environment and pulls their identities, groups, sessions, activity, and lifecycle state into one operational view. This guide covers safe console operations and the outcomes operators should verify.

Prerequisites

  • An Authdog project with the correct environment selected.
  • Console access limited to staff responsible for user support or administration.
  • A defined organization and role model for B2B users.
  • An approved identity-verification process for account recovery and MFA reset.
  • A test user for sign-in, suspension, session revocation, and reactivation exercises.

The same person in two environments is represented by two distinct user records. Always confirm the environment before changing a user.

Implementation

1. Choose the creation path

Self-service sign-up, social OAuth, enterprise SAML/OIDC (just-in-time on first sign-in), SCIM/HRIS provisioning, or console import for migrations. Authdog links multiple identities to one user only through a shared verified email, never depend on unverified email for merging.

2. Inspect users in context

Open Users in the intended environment, search for the user, and inspect profile data, active state, group memberships, recent activity, and sessions. Before changing access, identify where it comes from: direct assignment, organization membership, or IdP group mapping.

3. Import users for a migration

The console import accepts CSV, XLSX, and XLS up to 10 MB, with Auth0/Firebase templates available. It requires an email or username; review the preview's valid/invalid/warning counts before confirming. Never import plaintext passwords, only supported hash formats (bcrypt, scrypt, argon2, PBKDF2, SHA-256/512). Run a small test batch first.

4. Suspend and reactivate users

Suspend when offboarding, responding to compromise, or blocking access without deleting history. After suspension, verify new sign-in is blocked and existing sessions stop validating. When SCIM controls the user, make lifecycle changes upstream, a local reactivation can conflict with the next sync.

5. Review and revoke sessions

Expand a user's session view for status, expiry, and device context. Revoke a session when a device is lost or activity is suspicious, this forces reauthentication. For suspected compromise, combine revocation with suspension and MFA reset.

6. Support user self-service

The hosted Account Portal covers profile, credential, connected-account, and session management without an application redeploy. Keep privileged admin actions separate: verify identity outside a compromised factor before disabling MFA.

Security considerations

  • Confirm tenant, project, environment, and user before every destructive action.
  • Use verified email for identity linking, never merge accounts on an unverified address.
  • Keep imported hashes and personal data out of logs and tickets.
  • Suspend first when history must be preserved, deletion and suspension differ.
  • Enforce authorization on the backend even when state is shown in the client.

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

Duplicate user appears: compare provider identities and whether email was verified.

Profile change reverts: determine whether SSO, SCIM, or HRIS owns the field and update it upstream.

Suspended user still appears in search: expected, suspension preserves the record and history.

Next steps