A user is the core identity record in an environment. Every environment has its own isolated user store, so the same person signing into two of your environments is two distinct users. This page describes how users are created, how identities are linked, and how users connect to organizations and access control.

## How users are created

A user record is upserted on the first successful sign-in, regardless of method:

- **Self-service sign-up** — password or passwordless / magic link.
- **Social OAuth2** — Google, GitHub, Microsoft, Apple, and dozens more.
- **Enterprise SSO** — SAML 2.0 or OIDC, with the user created just-in-time (JIT) on first login.
- **[Provisioning](/docs/concepts/provisioning)** — created ahead of time via SCIM 2.0 or the HRIS connector, before the user ever signs in.

## Identity linking

A user can authenticate through more than one method. Authdog links these to a single user record by **verified email**: if someone signs up with a password and later signs in with a Google account that owns the same verified email, both identities resolve to the same user rather than creating a duplicate. Linking only happens on verified emails, so an unverified address can never claim an existing account.

## Profile and metadata

Each user carries a profile — email, name, and provider-supplied attributes — plus metadata you attach yourself. Use metadata to store app-specific fields (a plan tier, a preferred locale, an internal ID) that travel with the user and are available when you resolve a session. Profile fields sourced from SSO or HRIS are refreshed on subsequent sign-ins and provisioning syncs.

## Lifecycle state

A user is either **active** or **suspended**. Suspending a user immediately blocks new sign-ins and invalidates their ability to establish sessions, without deleting the record or its history — useful for offboarding or responding to a compromised account. Provisioning deactivations (an IdP removing a user) flow through to the same suspended state automatically.

## Users, organizations, and roles

Users are the members of [Organizations](/docs/organizations): a single user can belong to several organizations, each with its own org-scoped membership and roles. What a user is allowed to do is determined by your environment's authorization model — see [Roles & permissions](/docs/permissions) for how roles map to access. Group-to-role mappings from an IdP or HRIS can grant these roles automatically at provisioning time.

## Managing users

Manage users interactively in the [console](/docs/generated/console/dashboard/tenants) — search, inspect profiles, suspend or reactivate, and review sign-in activity. Everything the console does is also available through the REST API under `/v1/...`, so you can list, create, update, and suspend users programmatically from a [backend](/docs/backend).