Guides

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

Integrate your framework

Use the Framework guides to add Authdog to the 16 frontend and backend stacks we support. Each guide covers install, the callback, how the session behaves, and how that framework protects a route.

Structure multi-tenant workspaces

Use the platform hierarchy (Organization → Tenant → Project → Environment) so billing, admin memberships, and deployment stages stay apart. Create an organization when you need one billing umbrella. Use separate tenants for products or clients that shouldn't 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 connections you configure per environment. Enterprise SSO walks through the metadata exchange, domain routing, and how to test a connection before you hand it to the customer's IT team.

Provision users automatically

Keep your user store in step 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 prefixed adhris_), then map identity-provider or HRIS groups to roles. Membership changes grant and revoke access without a manual step.

Choose an authorization model

Every environment uses exactly one of three models. Pick the one that matches 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.

Authorization compares the trade-offs so you can pick one and stay with it.

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 the redirect URIs you allow, and subscribe to events with HMAC-signed webhooks (X-Authdog-Signature: t=...,v1=...). Delivery is retried, so you can use them for audit and downstream sync.

Migrate an existing user base

Move users from a legacy system into Authdog without forcing everyone to reset their password. If you're leaving a known provider, use that guide. Otherwise use bulk import, link identities by verified email, and cut over in phases so both systems can 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