Authdog

Guides

Last updated Jul 20, 2026
View as Markdown

Guides are task-oriented recipes for the things you build after your first sign-in works. Each one starts from a real goal — onboard an enterprise customer, pick an authorization model, harden 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.

Build a multi-tenant app

Model your B2B customers as Organizations: each organization has its own memberships, org-scoped roles, and invitations, all inside a single environment. This guide covers creating organizations, inviting members, and reading the active organization from a session claim so your app can scope data per customer.

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. This guide 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.

Learn more