Authdog

Guides

Last updated Sep 25, 2026
View as Markdown

Guides are for the work after the first sign-in works: enterprise SSO, an authorization model, hardening for production. Each one starts from a job you actually have. If you don't have a sign-in yet, start with a quickstart.

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

Learn more