Provisioning is how users and their access get created, updated, and removed automatically from a customer's own systems (their identity provider or HR platform) instead of by hand. For enterprise customers this is table stakes: when someone joins or leaves the company, their access to your app should follow without a support ticket.
The problem it solves
Without provisioning, every new hire at a customer signs up manually and every departure leaves a dangling account. Provisioning closes that loop by making the customer's directory the source of truth: their IdP or HRIS pushes changes to Authdog, and Authdog reflects them in your environment's user store and roles.
Authdog supports two inbound channels, both exposed as token-authenticated REST endpoints scoped to one environment.
SCIM 2.0: identity provider sync
SCIM (System for Cross-domain Identity Management) is the standard that IdPs like Okta, Entra ID, and JumpCloud speak to provision users and groups. Authdog exposes a SCIM 2.0 service:
- Endpoint:
/v1/scim/v2 - Auth: a bearer token prefixed
adscim_, issued per environment in the console - Resources: Users and Groups: create, update, deactivate, delete; group membership changes
The IdP is configured once with the endpoint and token; from then on it pushes user and group lifecycle events. Deactivating a user in the IdP suspends them in Authdog, which invalidates their sessions.
HRIS: HR-driven provisioning
Some organizations treat their HR system as the origin of truth rather than the IdP. Authdog's HRIS connector mirrors the SCIM slice for that world:
- Endpoint:
/v1/hris/v1 - Auth: a bearer token prefixed
adhris_ - Resources: Employees (users, with employment attributes like job title, manager, department, employment type, cost center, start/end dates) and Departments (groups)
This lets employment status, not just directory membership, drive access.
Group-to-role mapping
Provisioning users is only half the story; they also need the right access. Authdog maps directory groups (SCIM groups or HRIS departments) to roles automatically:
IdP group "Engineering" -> role "developer"
IdP group "Billing Admins" -> role "billing-admin"
HRIS department "Support" -> role "agent"When a user's group membership changes upstream, their roles are recomputed additively, so RBAC authorization stays in sync with the customer's org chart. Mappings match on group display name (case-insensitive) or external id (exact).
Deprovisioning
The security payoff. When someone is removed or deactivated upstream:
- their Authdog user is suspended or deleted,
- outstanding sessions stop validating on the next check,
- and group-derived roles fall away.
Access ends when employment ends, with no manual cleanup.
How it fits together
Provisioning tokens are scoped to one environment, and for enterprise customers provisioning pairs naturally with their enterprise SSO connection: the same customers who bring their own login also bring their own directory. Platform account structure (organizations and tenants) stays above the environment; provisioning mutates that environment's user store.
Related
- Users: the records provisioning creates and manages
- Roles & permissions: where group-to-role mappings land
- Authentication: enterprise SSO, provisioning's companion
- Integrations: the full connector catalog