Authdog
Log In

Enterprise guide

User Provisioning & SCIM

When the customer's directory is the source of truth, SCIM should be what creates and suspends people in Authdog.

Generate a token for one environment, point the IdP at it, map a group to a role, and deactivate a test user upstream until your app refuses the session. Do this in development or staging first. A bad sync against production is hard to undo.

Prerequisites

  • An Authdog Enterprise plan, with the project and environment already selected.
  • Administrator access to Provisioning → SCIM.
  • Administrator access to an IdP that speaks SCIM.
  • A test user and a test group in that IdP, neither of which can reach production data.
  • RBAC roles, if you plan to map groups to roles. Create the roles before the mapping, or the mapping has nothing to grant.

SCIM is per environment. The token you generate here will not provision another environment, and it should not.

Implementation

1. Generate a token and store it before you leave the page

Open the environment's SCIM provisioning page and copy the SCIM Base URL. The service path is /v1/scim/v2. The environment comes from the bearer token, not from a path segment you edit. Choose Generate token, name it after the customer and the IdP, and copy the full adscim_ value immediately. It is shown once. If you lose it, you rotate. You do not recover it.

2. Point the IdP at that URL and run one small sync

In the IdP, set the tenant or base URL to the SCIM Base URL, set authentication to bearer token, and paste the adscim_ token. Turn on only the User and Group operations you need. Start with identity fields both systems already understand. Run a test sync. Open the user in Authdog and read the profile before you map more attributes. A field you do not recognize yet is easier to fix on one user than on the whole directory.

3. Confirm the user, the group, and the token's last-used time

Assign one test user and one test group to the IdP app and trigger sync. In Authdog you want the user, the group, the user inside that group, and a Last used timestamp on the token that just moved. If the IdP says success and Last used did not change, you are looking at a different environment.

4. Map the group to a role, then re-apply

Under Group → Role Mapping, match by Group name (case-insensitive) or External ID (exact), and choose the role. If the group already exists, choose Re-apply to existing groups. A new rule does not rewrite people who synced yesterday until you do that.

Mappings add roles. They do not strip a role someone assigned by hand. If the test user has a direct assignment, you will still see it after you remove them from the group. That is expected. Clean direct assignments up separately, or your offboarding test will lie to you.

5. Deactivate upstream and watch access die

Deactivate the test user in the IdP and sync again. The Authdog user should be suspended or deleted, new sign-in should fail, and existing sessions should stop validating. Then remove the user from the test group, sync, and confirm the role goes away if it came only from that mapping.

If sign-in still works, you suspended a different user, or the app is not checking this environment's session. Hit the backend with the session you expect to be dead.

6. Name tokens so you can tell which one to kill

One token per integration, named so an on-call engineer knows which IdP it belongs to. Watch Last used. An idle token is either unused or pointed at the wrong place. Rotation replaces the secret immediately. There is no grace period, so update Authdog and the IdP in the same change window, then send a sync. Revocation marks the token inactive for good. Use it when you cannot trust the secret anymore.

Security considerations

  • A SCIM token can create and destroy users and groups. Treat it like a production admin credential.
  • Never put it in browser code, a ticket, chat, or logs.
  • Run the first sync and the deactivation test with non-production identities.
  • Rotate only when the IdP update is ready to go out with it. The old token dies at rotation.
  • Review direct role assignments. Group mapping will not remove them, and they will outlive the group.

Validation checklist

  • IdP uses the Base URL for the intended environment.
  • Bearer token begins with adscim_ and is stored only in the IdP.
  • Test user and group appear with expected identity fields.
  • Token Last used updates after sync.
  • Group mapping grants the intended role.
  • Upstream deactivation blocks user access.
  • Token rotation and emergency revocation are documented.

Troubleshooting

The IdP says unauthorized. Check the Bearer prefix, whether the token is still active, and that you are aimed at the environment that issued it. A rotated or revoked token fails this way on purpose.

The sync succeeds and no user appears. Read the IdP assignment and its provisioning log. Then confirm the environment in the console and whether Last used moved. Success against a different tenant looks like a missing user.

The group is there and the role is not. The mapping type or the value does not match the group, or you never re-applied the rule to a group that already existed. Fix the match, re-apply, and sync again.

Next steps