Users

The /admin/users area is the operational center for every human identity BluAuth knows about. Each row is a user record — a stable identity BluAuth owns, separate from the upstream provider identities it may be linked to. A user can sign in with a local password, with an enterprise provider, or both; the user record stays the same either way.

This is a frequently-used surface — expect to spend time here whenever someone reports they can't sign in, a new hire needs an account, or legal asks you to remove a former employee.

The user list

The list lives at /admin/users. It shows every user in the tenant, paginated.

Search

The search box matches against name and email. Fuzzy — "jsmith" will find "John Smith" and "smith.j@acme.com". Case-insensitive.

Filter

• Role — admin or user.
• Email verified — yes / no.
• Status — active, deactivated.
• Has password — useful for finding users who only sign in via an upstream provider.
• Recently signed in — last 7 days, last 30 days, never.

Filters combine — you can ask for "admins who have never signed in" in one query.

Sort

• Created at — newest first by default.
• Last sign-in — useful for finding dormant users.
• Role — groups admins at the top.
• Name / Email — alphabetical.

Inline row actions

Each row has a condensed action menu for common ops — you don't need to open the detail page for these. A confirmation modal fires for any destructive action.

• Toggle admin — promotes or demotes a user. Takes effect on their next session check (within ~60 seconds for most clients).
• Verify email — manually mark the user's email as verified. Useful for migrated users whose verification state didn't carry over.
• Generate temporary password — issues a one-time password and returns it once. Hand it to the user through a secure channel; the password hash is not stored anywhere the UI can show it again. On next sign-in, BluAuth forces a reset.
• Require password reset — flips requirePasswordReset on the user without generating a new password. Next time they authenticate, the force-reset concept fires before they reach their destination.
• Deactivate — reversible block on sign-in. See "Deactivation vs deletion" below.
• Delete — hard-delete. Confirmation modal makes you type the user's email to proceed.

The user detail page

Clicking a row opens /admin/users/:id. The detail page is divided into panels:

Identity

The user's canonical record — ID, email, name, role, createdAt, updatedAt, email verification status, and active/deactivated flag. Editable inline (name, role) — saves atomically.

Linked providers

Every upstream provider identity this user has connected. Shows:

• Provider type (Google, Microsoft, Okta, OIDC, SAML, local).
• Provider's subject identifier (the upstream user's stable ID).
• Email on the provider side (may differ from the BluAuth email if the user linked manually).
• Date the link was created.
• Unlink action — removes the link. The user can re-link on next sign-in.

A user can have multiple providers plus a local password. The local password row appears here only if the user has set one — upstream-only users show with no local row.

Password status

• Has password — yes / no.
• Password set at — when the hash was last updated.
• Requires reset — whether requirePasswordReset is flipped on.
• Last password verification — last time the password was successfully verified at sign-in.

From this panel:

• Set temporary password — same as the inline action, more prominently placed.
• Clear password — removes the local password entirely. The user can only sign in via upstream providers after this. Reversible — they can set a new one via the forgot-password flow.

Sessions

Active and recent sessions, including issuer, client, IP, user-agent, and last activity. Each row has a Revoke action — kills the session immediately. Downstream access tokens still age out on their normal TTL, so treat session revocation as immediate BluAuth logout plus eventual token expiry. Use when an account is suspected compromised.

Recent events

The last 50 audit events for this user — sign-ins, failed sign-in attempts, password resets, role changes, session revocations, invitation acceptances. Every admin action on the user writes to this stream. Event types follow the webhook events schema.

SSO history

A timeline view of every successful SSO completion, grouped by provider. Useful for troubleshooting "I can't sign in with Google" — you can see whether the last successful Google sign-in was last week or last year.

Audit logging

Every action in the admin users area writes an audit event. Events are immutable and stored for the tenant's configured retention window (default: 12 months).

Events published:

• user.created, user.updated, user.deleted
• user.role.changed
• user.password.reset-requested, user.password.reset-completed, user.password.temporary-issued
• user.session.revoked
• user.provider.linked, user.provider.unlinked
• user.deactivated, user.reactivated

The events panel on the user detail page is a filtered view of the service-wide audit stream (/admin/audit). Webhook subscribers receive the same events — see webhook events reference.

Creating users manually

You can create a user directly from /admin/users. Prefer invitations over direct creation — they put the password-setting step on the user, which is cleaner. Direct creation is available for:

• Migrations — scripted imports where you already have hashed credentials.
• Machine accounts — bot users with specific scopes.
• Help-desk scenarios — the rare case where a user must be created in-band during a support call.

Force-reset

requirePasswordReset is a flag on the user record that forces the force-reset concept on their next authentication. The studio exposes force-reset copy overrides — see concept copy.

Use force-reset when:

• A user's password may have been compromised (you don't want to wait for them to rotate voluntarily).
• Your password policy changed and you want users to move up to the new minimum strength.
• You've issued them a temporary password and want to ensure they set their own.

Force-reset is honored by your service-settings password policy (min length, char classes, breach check via HaveIBeenPwned). Policies live at /admin/settings.

Deactivation vs deletion

Prefer deactivation unless you have a specific legal or compliance reason to delete. Deactivation preserves the audit trail fully; deletion anonymizes the user reference in future events (past events retain historical data).

Deletion publishes user.deleted to the webhook stream. Downstream apps subscribed to the event should delete their local copy of the user's data.

Handling duplicate accounts (merge workflow)

Sometimes the same human ends up with two BluAuth records. Common causes:

• They signed in with Google once (creating user A), then with email/password using a different address (creating user B), then linked Google to B but A persists.
• A migrated user was imported with a different email case, and they signed up again with the canonical case.

To merge:

1. Open the user detail page for the source (the duplicate you want to get rid of).
2. Click Merge into… at the top right.
3. Search for the target (the user record you want to keep).
4. BluAuth shows a merge preview: which sessions move, which providers move, which audit events re-associate.
5. Confirm. The source user's linked providers, sessions, and events re-point to the target; the source record is deleted.

The merge is atomic but not reversible — the preview is where you stop if anything looks wrong. Both users must be in the same tenant. Conflicts (e.g. both users have a local password) are flagged in the preview: the target's password wins, and a user.password.cleared event fires for the source.

Password policies

Password policies live at /admin/settings and apply to every user in the tenant. Policy fields:

• Minimum length — default 8, configurable up to 128.
• Require uppercase / lowercase / digit / symbol — per-class booleans.
• Block common passwords — HaveIBeenPwned breach check. On by default; should stay on.
• Password history — prevents reuse of the last N passwords. Default 5.

Policy changes apply at the next password-setting event — existing passwords aren't retroactively invalidated. To force rotation, use force-reset.

Common scenarios

• User forgot their password and the reset email didn't arrive — check their linked providers (they may be signing up via SSO without a password); else use Generate temporary password and hand it off.
• User's account was compromised — deactivate, revoke all sessions on the detail page, then let them re-verify ownership before reactivating.
• User left the company — deactivate. If there's a legal erasure requirement, delete instead.
• Two accounts for the same person — use the merge workflow.
• Migrating bulk users — use the admin API, not the UI. See the invitations guide for bulk onboarding.

Next

• Invitations — the preferred way to onboard new users.
• Clients — bind users to downstream apps via OAuth clients.
• Providers — configure the upstream identity providers users authenticate against.