Guides

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 instead.

Integrate your framework

Use the Framework guides 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 → Tenant → 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.

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 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. 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 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 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: export tenants, map identities and roles, preserve passwords or run progressive migration, then cut over applications in stages.
• Migrate from Amazon Cognito: export user pools and groups, preserve sub identifiers, choose a credential transition, and move applications by pool or cohort.
• Migrate from Clerk: move users, organizations, memberships, and external accounts while replacing Clerk session validation in stages.
• Migrate from Descope: map users, tenants, roles, and authentication methods into Authdog environments and organizations.
• 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: move consumer or B2B users, organizations, and authentication methods without treating active Stytch sessions as portable.
• Migrate from WorkOS: move AuthKit users, organizations, SSO connections, and Directory Sync with a staged B2B cutover.
• 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: map adapter records, accounts, sessions, organizations, and plugins into explicit Authdog resources.
• Migrate from another identity system: inventory a custom user store, preserve source identifiers, test credential compatibility, and plan rollback before cutover.

Related

• Users: the user object and lifecycle.
• Backend requests: server-side session validation.
• Account portal: hosted, zero-config auth UI.