---
title: "SCIM provisioning"
description: "The Better Auth SCIM 2.0 runtime enabled for StackShip identity provisioning and deactivation."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.stackship.run/llms.txt
> Use this file to discover all available pages before exploring further.

# SCIM provisioning

StackShip enables the `@better-auth/scim` plugin in the production identity
runtime with provider ownership enabled. SCIM provisioning is separate from
interactive sign-in and from StackShip product tokens.

There is no billing or seat-management surface today.

## Runtime boundary

Better Auth owns the SCIM protocol routes, provider records, bearer
authentication, resource validation, and provider-owned identity lifecycle.
The StackShip API mounts Better Auth at:

```text
https://api.stackship.run/api/auth
```

Use the base URL, token, resource support, and schema advertised by the exact
deployed Better Auth version. StackShip documentation does not invent a stable
private SCIM URL, token prefix, rotation window, group mapping, or bulk limit
that the runtime has not committed.

## Current administration surface

The dashboard organization page reads members and invitations through the
Better Auth organization plugin. It does not currently create SCIM providers,
issue or rotate SCIM credentials, present reconciliation reports, or manage
group-to-role mappings.

SCIM provider provisioning is an operator-assisted Better Auth workflow today. The presence of a member in the directory does not prove which
provider provisioned it or whether SCIM synchronization is healthy.

## Authorization

SCIM manages identity records; it does not grant StackShip product permissions
directly. Product access still requires:

1. a valid authenticated identity;
2. a live membership in the active organization; and
3. the fixed permission mapping for that membership role.

Unknown or stale roles grant nothing.

## Deactivation

The Better Auth admin plugin is enabled because the SCIM `active` lifecycle
uses the account's banned state to deactivate a user and revoke sessions.
Deactivation must not delete run, state, policy, source, or audit evidence that
belongs to the organization.

Before enabling a provider in production:

- test create, update, deactivate, and reactivate against non-production
  identities;
- verify tenant isolation with two organizations;
- verify session revocation;
- store the provisioning credential only in the identity provider's secret
  field; and
- retain an operator recovery identity outside the provider being tested.

## Related pages

- [Authentication](/authentication)
- [Enterprise SSO](/admin/sso)
- [Organization administration](/admin)
- [Roles and permissions](/admin/teams)

Source: https://docs.stackship.run/admin/scim/index.mdx