SCIM user and group provisioning

Manual user create does not scale when a customer's IdP is already the source of truth. Authdog now exposes SCIM 2.0 so enterprise directories can provision users, groups, and role mappings through the same APIs those IdPs already speak.

This is the longer note behind the June 27 changelog entry.

How it works

The SCIM service supports discovery, filtering, and patch operations on users and groups. The IdP pushes create, update, deactivate, and membership changes; Authdog reflects them in the environment user store.

Access is a scoped SCIM token you create, rotate, and revoke in the console. The token, not the URL, selects the environment.

Directory groups map to Authdog roles. When membership changes upstream, role grants follow the mapping so RBAC stays aligned with the customer's org chart. How that fits with sessions and deprovisioning is in Provisioning.

Set it up

In the console, open Users > Provisioning and the SCIM tab:

1. Copy the SCIM base URL into the IdP.
2. Generate a bearer token and store it in the IdP. The value is shown once.
3. Add group-to-role mappings (group name to an Authdog role).
4. Trigger a provisioning cycle from the IdP and confirm users and groups land in Users.

Rotate or revoke a token when an IdP integration is rebuilt or a secret leaks. A revoked token stops inbound SCIM for that credential immediately.

Trust boundaries

The IdP is the source of truth for provisioned users and groups. A SCIM token is a privileged write credential for that environment; treat it like a directory admin secret. Deactivating a user upstream suspends them in Authdog and invalidates sessions on the next check.

Group-to-role mapping is additive from matched groups. It does not replace roles you assign by hand, and it does not evaluate FGA tuples.

Try it

Product overview is on User management. Console steps are in Users. The original release note is in the changelog.