Authdog
Log In

Platform guide

Enterprise Ready

Identity is enterprise-ready when a bad change stays in staging and a broken customer SSO does not take down everyone else.

Work through isolated environments, customer SSO, automated provisioning, server-side authorization, and an audit trail you can export. Do it in that order, in a non-production organization, before you touch a live customer.

Prerequisites

  • An Authdog tenant, project, and separate dev, staging, and production environments.
  • A production application that validates the Authdog session on the backend.
  • An organization model for B2B customers who bring their own SSO or directory.
  • Named owners for identity config, customer onboarding, support recovery, and access reviews.
  • A test organization and a test IdP tenant that cannot see production data.

Implementation

1. Separate the blast radius before you configure anything

One project per application. One environment per stage. A session minted in development must fail against production's keys. That failure is the isolation working. Keep it.

Model each B2B customer as an organization inside production, not as its own environment. Environments are for your deploy stages. Organizations are for their companies. If you mix those, every new customer becomes an environment you have to operate.

2. Pick one sign-in surface and stick to it

Choose the hosted Account Portal, embedded components, or a custom flow. Enable only the methods that environment needs. For an enterprise customer, add SAML or OIDC and route by email domain. Test with one user on a non-overlapping domain before you announce it. The connection steps are in Authentication and SSO.

3. Let the customer's directory hire and fire

When their IdP is the source of truth, turn on SCIM 2.0. An environment-scoped bearer token lets that IdP create, update, deactivate, and delete users and groups. Map groups to roles. When you add a mapping, re-apply it to groups that already exist, or those people keep their old access. Deactivate a test user upstream and confirm your backend rejects the session. The wiring is in User provisioning with SCIM.

4. Make the backend the thing that says no

Pick one model per environment: RBAC, ABAC, or FGA. Start with a few permissions and a small set of roles. Hide buttons in the client if you want. The route still has to check. See Authorization and access control. You are done when a missing session and a session from the wrong organization both fail closed.

5. Keep evidence you can hand to someone else

Use audit to investigate sign-ins, role changes, and admin actions. Filter by environment, time, and user. Copy the raw event before you remediate, because the next change will not contain the payload you needed. Use the Events API or webhooks when another system has to react. Webhook consumers verify the HMAC signature and deduplicate on delivery ID. If you need a retention policy, export into storage you control. Authdog's console is the investigation view, not your archive.

Security considerations

  • Keep API tokens, client secrets, SCIM tokens, and Admin Portal links out of browser code and logs.
  • Use HTTPS for every callback, and track SAML certificate expiry so a rotation does not become an outage.
  • Keep SSO discovery domains from overlapping. First match wins, and a parent domain includes its subdomains.
  • Keep a tested recovery sign-in while you change SSO or MFA. Change one control at a time.
  • Rotate SCIM tokens only when the IdP can be updated in the same window. The old secret stops immediately.
  • Put audit exports in storage you govern, under your retention rules.

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 land on the wrong IdP. Two connections claim overlapping domains. Remove the overlap. A parent domain also matches its subdomains, so customer.com and eu.customer.com on different connections will fight.

SSO works in staging and fails in production. Callback, entity ID, certificate, and active state are per environment. Compare them one field at a time. Do not copy the staging certificate into production and hope.

A provisioned user has an account and no access. The group synced, but the role mapping does not match, or you never re-applied it to groups that already existed. Fix the mapping, re-apply, and sign in again.

Next steps