Guides are task-oriented recipes for the things you build after your first sign-in works. Each one starts from a real goal, such as onboarding an enterprise customer, picking an authorization model, or hardening for production, and walks the concrete steps. If you are just getting started, begin with the [Quickstarts](/docs/quickstarts) instead.

## Integrate your framework

Use the [Framework guides](/docs/guides/frameworks) to add Authdog to 16 supported frontend and backend stacks. Guides cover installation status, callback handling, session behavior, route enforcement, and framework-specific security boundaries.

## Structure multi-tenant workspaces

Use the platform hierarchy — [Organization](/docs/concepts/organizations) → [Tenant](/docs/console/tenants) → Project → Environment — so billing, admin memberships, and deployment stages stay isolated. Create an organization when you need a shared billing umbrella; use separate tenants for products or clients that should not share projects or teams. See [Multi-tenancy](/docs/concepts/multi-tenancy).

## Onboard enterprise SSO

Let a customer sign in with their own identity provider over SAML 2.0 or OIDC. Okta, Microsoft Entra ID, JumpCloud, Ping Identity, and BeyondTrust are first-class connections you configure per environment. The [Enterprise SSO](/docs/sso) page walks the metadata exchange, domain-based routing, and testing a connection before you hand it to the customer's IT team.

## Provision users automatically

Keep your user store in sync with a customer's directory using [provisioning](/docs/concepts/provisioning). Set up SCIM 2.0 (`/v1/scim/v2`, tokens prefixed `adscim_`) or the HRIS connector (`/v1/hris/v1`, tokens `adhris_`), then map IdP or HRIS groups to roles so membership changes grant and revoke access without manual work.

## Choose an authorization model

Every environment uses exactly one of three models: pick per environment based on how your access rules are shaped:

- **RBAC**: roles grant permissions; best for seat-based, role-driven apps.
- **ABAC**: attribute policies written in Rego, evaluated at the edge.
- **FGA**: Zanzibar-style relationship tuples for fine-grained, per-object access.

The [Authorization](/docs/concepts/authorization) concept page compares the trade-offs so you can commit with confidence.

## Harden for production

Before you ship: use a separate environment per stage (dev, staging, production) so keys and connections never cross. Rotate signing keys on a schedule, restrict allowed redirect URIs, and subscribe to [events](/docs/backend) via HMAC-signed webhooks (`X-Authdog-Signature: t=...,v1=...`) with durable retry for audit and downstream sync.

## Migrate an existing user base

Move users from a legacy system into Authdog without forcing a mass password reset. Prefer provider-specific guides when you are leaving a known IdP; otherwise use bulk import, identity linking by verified email, and a phased cutover where both systems validate sessions during the transition.

- [Migrate from Auth0](/docs/guides/migrate-from-auth0): export tenants, map identities and roles, preserve passwords or run progressive migration, then cut over applications in stages.
- [Migrate from Amazon Cognito](/docs/guides/migrate-from-cognito): export user pools and groups, preserve `sub` identifiers, choose a credential transition, and move applications by pool or cohort.
- [Migrate from Clerk](/docs/guides/migrate-from-clerk): move users, organizations, memberships, and external accounts while replacing Clerk session validation in stages.
- [Migrate from Descope](/docs/guides/migrate-from-descope): map users, tenants, roles, and authentication methods into Authdog environments and organizations.
- [Migrate from Firebase](/docs/guides/migrate-from-firebase): export Firebase Authentication users, retain `uid` as an external identifier, translate custom claims, and switch clients off Firebase ID tokens.
- [Migrate from Stytch](/docs/guides/migrate-from-stytch): move consumer or B2B users, organizations, and authentication methods without treating active Stytch sessions as portable.
- [Migrate from WorkOS](/docs/guides/migrate-from-workos): move AuthKit users, organizations, SSO connections, and Directory Sync with a staged B2B cutover.
- [Migrate from Supabase](/docs/guides/migrate-from-supabase): export `auth.users`, preserve Auth UUIDs for RLS joins, import bcrypt hashes when possible, and retire Supabase JWTs.
- [Migrate from Better Auth](/docs/guides/migrate-from-better-auth): map adapter records, accounts, sessions, organizations, and plugins into explicit Authdog resources.
- [Migrate from another identity system](/docs/guides/migrate-from-other): inventory a custom user store, preserve source identifiers, test credential compatibility, and plan rollback before cutover.

## Related

- [Users](/docs/users): the user object and lifecycle.
- [Backend requests](/docs/backend): server-side session validation.
- [Account portal](/docs/account-portal): hosted, zero-config auth UI.