Provisioning

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 and case-insensitively — so RBAC authorization stays in sync with the customer's org chart. Mappings are matched by group display name or external id.

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 — no manual cleanup.

How it fits together

Customer IdP / HRIS ──(SCIM / HRIS push)──▶ Authdog environment
                                             ├── upsert user
                                             ├── sync group membership
                                             └── apply group -> role mapping
Your app ◀── authorized requests, always current

Provisioning is configured per organization for enterprise customers, alongside their enterprise SSO connection — the same customers who bring their own login also bring their own directory.

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