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:
https://api.stackship.run/api/authUse 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:
- a valid authenticated identity;
- a live membership in the active organization; and
- 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.