User Management

User management is available on all plan tiers and all providers. What each provider can do differs, so AUMS only offers the actions and filters the connected provider supports.

Users list

The users page (/users) lists the users of your provider. You can:

• Search by name or email (Ory only matches a whole email or ID)
• Filter by status (active, blocked), email verification and phone verification
• Sort and paginate (the provider decides which columns can sort)
• Select several users to block, unblock or delete them in one go

Some providers refuse certain combinations of filters (Cognito: search with the status filter; Keycloak: search with email verification). The controls that conflict are disabled, with a note saying why.

More filters

More filters adds filters most provider APIs don’t have:

Filter	Needs
Created after	the provider reports a creation date (all do)
Last login before	the provider reports last logins (Auth0, Entra, Firebase)
Never signed in	same
Email domain	nothing: matches @domain exactly, not sub-domains

Providers can’t apply these themselves, so AUMS reads the users page by page and filters them. It stops after 2,000 users and says so when that happens: narrow the search to be sure of seeing every match.

Views

The Views menu offers ready-made views (such as Inactive for 90+ days, Never signed in, Signed up in the last 30 days, Blocked users: only those the provider can answer) and your saved views. Save the current search, filters and sort order under a name; saving under an existing name replaces it. Saved views are personal and keep fixed dates.

User detail

Click a user to open the detail page. It shows:

Section	Description
Profile	Name, email, phone, picture; editable
Roles / groups	Assign roles or groups (see below)
Metadata	Metadata, attributes or custom claims; editable (see below)
Identities	Linked social and enterprise logins; unlink them where supported
Sessions	Active sessions with device and IP, where the provider lists them
Activity	Recent authentication events (provider-dependent)

Support actions

The Actions menu on the detail page runs the actions the provider supports. Each one is recorded in the admin audit trail.

Action	Auth0	Keycloak	Ory	Cognito	Firebase	Entra	SCIM	SuperTokens
Block / unblock	✅	✅	✅	✅	✅	✅	✅	—
Send password reset email	✅	✅	—	✅	—	—	—	—
Resend verification email	✅	✅	—	—	—	—	—	—
Reset MFA	✅	✅	✅	✅	—	—	—	—
List sessions and sign out	✅	✅	✅	—	—	—	—	—
Sign out everywhere only	—	—	—	✅	✅	✅	—	—
Unlink an identity	✅	✅	—	—	✅	—	—	—

Caution

Keycloak, Ory and SCIM are covered by tests against real servers. The Auth0, Cognito, Entra and Firebase implementations are type-checked and share the tested logic, but have not been run against live tenants.

Keycloak sends the password reset and verification emails through the realm’s email settings: configure them in Keycloak first. Firebase signs the user out by revoking refresh tokens; already issued ID tokens stay valid until they expire (up to an hour). Resetting MFA and signing out ask for confirmation.

Roles and groups

Where the provider has them, the detail page lists the roles (Auth0, Keycloak realm roles) or groups (Cognito, Entra security groups) you can assign, with checkboxes. Roles Keycloak assigns to everyone by itself are not offered, nor are Entra groups whose membership is computed. At most 500 are listed. Changes are recorded with the names of the roles added and removed.

Metadata

Where the provider can store free-form data on a user, the metadata card has an Edit button with a JSON editor, checked as you type and again on the server:

Provider	What is editable	Limits
Auth0	User metadata and app metadata	JSON, 16 KB each, Auth0’s reserved keys refused
Keycloak	Attributes	text, numbers, booleans or lists of them; 8 KB
Firebase	Custom claims	JSON, 1,000 bytes, standard token claims refused

Saving replaces the bucket: keys you leave out are removed. The audit trail records the names of the keys, never their values.

Note

Keycloak silently drops attributes its user profile doesn’t declare unless Unmanaged attributes is enabled (Realm settings, General). AUMS detects this and tells you instead of reporting a success.

Create user

From the users list, click Create user. Required: an email address. Name, password and the verified flag are optional; what else a provider accepts varies.

Import and export

Import takes a CSV file with an email column and, optionally, name and email_verified (true or false): download a template from the dialog. Up to 2,000 users and 1 MB per file. AUMS previews the file, skips rows with problems (invalid or repeated emails) and tells you which, then creates the users a few at a time with a progress bar. Each creation is recorded as if you had created the user by hand. Failures (a user that already exists, for example) are listed and can be downloaded as CSV. Passwords are not imported.

Export CSV downloads the users of the current search, filters included, with their id, email, name, verification and blocked status, phone, creation date and last login (up to 10,000 users). It needs write access, not just read, since it hands over everyone’s personal data, and it is recorded in the audit trail. Cells a spreadsheet would run as a formula are neutralized.

Delete user

Caution

Deleting a user is permanent and removes them from your provider. This cannot be undone.

Deleting asks you to type the user’s email (or delete for several users) and to give an optional reason, which is kept in the audit trail. On the Business tier a second admin can be required to approve deletions.