Authdog

Platform guide

Enterprise Ready

Enterprise readiness means identity stays boring and predictable when something goes wrong. This guide turns Authdog's building blocks, isolated environments, customer SSO, automated provisioning, server-side authorization, operational evidence, into a staged rollout.

Prerequisites

  • An Authdog tenant, project, and separate dev/staging/production environments.
  • A production application that validates Authdog sessions on the backend.
  • An organization model for B2B customers with their own SSO or directory.
  • Named owners for identity config, onboarding, support recovery, and access reviews.
  • A non-production test organization and test IdP tenant.

Implementation

1. Establish environment boundaries

One project per application, separate environments per deployment stage. A session minted in one environment never validates against another's key, that isolation is a feature. Model each B2B customer as an organization inside production, not as its own environment.

2. Standardize authentication

Pick one sign-in surface (hosted Account Portal, embedded components, or custom flow) and enable only the methods each environment needs. For enterprise customers, configure SAML or OIDC and route by email domain. See Authentication and SSO.

3. Automate joiner and leaver workflows

Use SCIM 2.0 when a customer's IdP is the source of truth: an environment-scoped bearer token lets the IdP create, update, deactivate, and delete users and groups. Map groups to roles, and re-apply mappings when you add new rules. See User provisioning with SCIM.

4. Enforce authorization on the backend

Pick one model per environment, RBAC, ABAC, or FGA, start with granular permissions and a small role set. Client-side checks shape the UI; they never protect the action. See Authorization and access control.

5. Build operational evidence

Use audit views to investigate sign-ins, role changes, and admin actions, filtered by environment, time, and user. Preserve raw event data before remediation. Use the Events API or webhooks for downstream reactions; webhook consumers must verify the HMAC signature and deduplicate delivery IDs.

Security considerations

  • Keep API tokens, client secrets, SCIM tokens, and Admin Portal links out of browser code and logs.
  • Use HTTPS everywhere and track SAML certificate expiry.
  • Avoid overlapping SSO discovery domains, first-match resolution can route unpredictably.
  • Keep a tested recovery sign-in path while changing SSO or MFA policy.
  • Rotate SCIM tokens deliberately, the old secret stops working immediately.
  • Export audit evidence to storage you control under your own retention policy.

Validation checklist

  • Development sessions fail validation against production configuration.
  • Each customer organization sees only its own memberships and roles.
  • SAML or OIDC test sign-in succeeds with a stable subject and verified email.
  • SCIM test user and group appear in the intended environment.
  • Upstream deactivation suspends the user and blocks session validation.
  • Protected backend routes deny missing or insufficient sessions.
  • Recovery and token-rotation procedures have been exercised in staging.

Troubleshooting

Users reach the wrong IdP: remove overlapping discovery domains; a parent domain also matches its subdomains.

SSO works in staging but not production: compare callback, entity ID, certificate, and active state, these are environment-specific.

Provisioned user has no access: confirm the group synced, the mapping matches, and it was re-applied to existing groups.

Next steps