Authdog
Identity guide

User Management

Authdog stores users per environment and brings their identities, groups, sessions, activity, and lifecycle state into one operational view. Users can be created by self-service sign-up, social login, enterprise SSO, SCIM, HRIS provisioning, or controlled import. This guide focuses on safe console operations and the observable 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.
  • For bulk migration, a reviewed CSV or spreadsheet export that excludes plaintext passwords.

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

Implementation

1. Choose the creation path

Use the path that matches the identity source:

  • Self-service sign-up for password or magic-link users.
  • Social OAuth for supported external providers.
  • Enterprise SAML or OIDC for just-in-time creation on first successful sign-in.
  • SCIM or HRIS when a customer directory should create users before first sign-in.
  • Console import for controlled migrations.

Authdog links multiple identities to one user only when they present the same verified email. Do not depend on unverified email for account merging.

For enterprise lifecycle automation, use Authentication and SSO with User provisioning with SCIM.

2. Inspect users in context

Open the console's Users area in the intended environment. Search for the user and inspect identity/profile data, active state, group memberships, recent activity, and sessions.

A user can belong to multiple organizations and hold different organization-scoped roles. Before changing access, identify whether it comes directly from the user, from organization membership, or from an IdP group mapping. See Authorization and access control.

Profile data can include email, name, provider-supplied attributes, and application metadata. Fields sourced from SSO or provisioning may be refreshed by later sign-ins or syncs, so change the source of truth rather than repeatedly overriding downstream values.

3. Import users for a migration

The console import flow accepts CSV, XLSX, and XLS files up to 10 MB. Download a sample, Auth0, or Firebase template when applicable. Supported fields include email, username, display name, provider, active state, external ID, name fields, locale, timezone, last login, and optional password hash information.

The import requires an email or username. Review the preview's valid, invalid, and warning counts, select only intended valid rows, then inspect the final success and failure summary.

Never import plaintext passwords. The console expects password material to be hashed and identifies supported algorithm labels including bcrypt, scrypt, argon2, PBKDF2, SHA-256, and SHA-512. Treat any password-hash export as sensitive credential material, restrict access, and remove temporary copies after the migration.

Run a small test batch first. Confirm that imported users can complete the intended authentication flow before importing the remaining population.

4. Suspend and reactivate users

Authdog users have active and suspended lifecycle states. Suspend a user when offboarding, responding to compromise, or temporarily blocking access without deleting the record and its history.

After suspension, verify that new sign-in is blocked and existing sessions no longer provide access on validation. Reactivate only after confirming the upstream directory state, support authorization, and intended role assignments.

When SCIM controls the user, make lifecycle changes in the upstream IdP. A local reactivation can otherwise conflict with the next provisioning update.

5. Review and revoke sessions

Expand the user details view to inspect sessions. The console exposes status, creation and expiry information, browser/device context derived from user agent, and available location context. Revoke an active session when a device is lost, activity is suspicious, or support needs to force reauthentication.

Session revocation logs the user out from that session and requires authentication again. For suspected compromise, combine revocation with suspension, credential or MFA recovery, and audit review according to incident scope.

6. Support user self-service

The hosted Account Portal provides profile, credential, connected-account, and active-session management alongside sign-in, sign-up, and MFA screens. It reflects the environment's current connections and policies without an application redeploy.

Keep privileged administrator actions separate. Verify identity outside a compromised factor before disabling MFA, then have the user enroll a new authenticator and review audit activity.

Security considerations

  • Confirm tenant, project, environment, organization, and user before every destructive or access-changing action.
  • Use verified email for identity linking; never merge accounts based on an unverified address.
  • Keep imported hashes, API tokens, and personal data out of logs and support tickets.
  • Suspend first when history must be preserved; deletion and suspension have different operational outcomes.
  • Treat MFA reset and session revocation as privileged recovery actions.
  • Enforce authorization on the backend even when user state and roles are displayed in the client.
  • Let the configured directory remain the source of truth for provisioned users.
  • Restrict audit exports and define retention in your controlled destination; Authdog documentation does not promise a fixed retention period.

Validation checklist

  • Operator selected the intended environment.
  • Test user was created through the intended source.
  • Verified-email linking avoids a duplicate identity.
  • Organization memberships, groups, and roles match expected access.
  • 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.
  • Reactivation restores only intended access.
  • User can complete approved Account Portal self-service tasks.

Troubleshooting

Duplicate user appears: compare provider identities and whether email was verified. Linking does not use unverified email.

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

Imported row is invalid: ensure email or username exists, email format is valid, and local-user password data is a supported hash rather than plaintext.

Suspended user still appears in search: expected behavior. Suspension blocks access but retains the record and history.

User retains access after group removal: inspect direct and organization-scoped roles in addition to group-derived roles.

Revoked session seems active: refresh the session view and test a protected backend request; client UI state alone is not authoritative.

Next steps