Identity & Provisioning (SCIM)
Sync users and groups from your identity provider (Microsoft Entra, Okta, OneLogin) into Scrydon using SCIM 2.0 — automated provisioning, deprovisioning, and group membership.
Scrydon supports SCIM 2.0 (System for Cross-domain Identity Management) so your identity provider can automatically create, update, and deactivate users in Scrydon — and keep group membership in sync — without any manual admin work on the Scrydon side.
SCIM provisions directory records and organization access. It does not create
sign-in credentials or automatically link an SSO identity. Configure and test
the user's sign-in path separately under Settings → Platform → Identity.
What SCIM does
| Action in your IdP | Result in Scrydon |
|---|---|
| Assign a user to the Scrydon app | A new directory user is created, or an eligible existing member is linked to your org |
| Update a user's name or attributes | The directory record changes; the global profile changes only when that SCIM source owns it |
| Remove a user from the Scrydon app | Organization access is removed when no active source remains for that org; the global account and sessions are preserved |
| Add a user to an IdP group assigned to Scrydon | User is added to the matching Scrydon Team |
| Remove a user from an IdP group | User is removed from the Scrydon Team |
| Create a new IdP group assigned to Scrydon | A new Scrydon Team is created with the group's display name |
| Delete an IdP group | The Scrydon Team's SCIM link is removed, but the Team itself is preserved so history is not lost |
Nested groups
SCIM groups in Scrydon can contain other groups as members, not just users. Scrydon flattens the effective membership when syncing to a Scrydon team:
- A team always shows the effective user list — direct users plus transitive users from any nested sub-groups.
- Nesting is supported up to 3 levels deep (parent → child → grandchild).
- Cycles (group A contains group B, which contains group A) are rejected.
- When you update a nested group's membership, all parent groups that contain it are re-synced on the next operation.
What SCIM does not do
- Does not adopt outside accounts by email. An existing account can be
linked only when its email is verified and it already belongs to the token's
organization. Invite the user and have them accept before provisioning.
Outside or unverified matches return an email conflict (
409). Linked accounts retain their global profile; newly created identities grant their SCIM source explicit profile authority. - Does not rename existing teams. If you rename a group in your IdP, the linked Scrydon Team keeps its original name. Rename the team directly in Scrydon if you want to change it.
- Does not sync service principals / machine accounts. Only human identities. Create service accounts directly in Scrydon.
- Does not delete user records on deprovisioning. Users are deactivated for the token's organization, but the underlying user row is preserved so audit history and owned resources stay intact. If the same user is re-provisioned later (a rehire, for instance), Scrydon automatically reactivates the existing record rather than creating a duplicate.
Prerequisites
- Org admin role — only org admins can generate or revoke SCIM tokens. Org owners and admins can also manage the organization's SSO connections (view, update enforcement, rotate signing certificates, remove), not only the person who first configured one — so SSO stays manageable when that person leaves.
- A tested sign-in path — SCIM does not supply credentials. Verify native sign-in or an explicitly linked SSO identity before relying on provisioned access.
- One of the supported IdPs — this release covers Microsoft Entra ID (Azure AD), Okta, and OneLogin. Any RFC 7644-compliant SCIM 2.0 IdP should work, but those three are the ones we test against.
Choose your identity provider
Scale limits
Scrydon enforces per-organization caps to protect shared infrastructure from runaway provisioning. If your organization needs higher limits, contact support — these are guardrails, not architectural ceilings.
| Resource | Limit |
|---|---|
| Users per organization | 10,000 |
| Groups per organization | 1,000 |
| Members per group | 2,000 |
| Nested group depth | 3 levels |
| SCIM API requests | 20 per second per organization |
How deprovisioning works
When a user is removed from the Scrydon app in your IdP (or the IdP marks them as inactive), Scrydon performs a soft delete:
- The user is removed from the organization when no active SCIM source remains for that organization. Requests requiring that membership are denied.
- SCIM-controlled team memberships are reconciled within that organization.
- The global account and sessions remain usable for other organizations. SCIM neither sets nor clears a platform operator's account ban.
- The underlying user record is preserved, so audit history, owned resources, and compliance trails remain intact.
Email code sign-in happens on the sign-in page itself: after you choose Email me a code, the page shows the masked address the code went to (for example xa***@example.com) and a six-digit entry field. The page keeps your place if you refresh or return from your mail app, and Resend code becomes available after a short wait. Codes expire after 15 minutes; an expired code offers Send a new code.
Email sign-in links work the same way, without anything to type: choose Email me a sign-in link and the page confirms which masked address it went to. Open the link on the same device or a different one to finish signing in — it works once and expires shortly. Unlike the code step, this screen is not restored after a refresh: the link is already in your inbox and stays valid, so you can simply open it. If a link has already been used or has expired, the page says so and offers a way back to sign-in rather than leaving you waiting.
If the user is re-added in the IdP later, SCIM re-provisioning will
reactivate the same record — the same userId is used, so audit
history is continuous.
Token security
SCIM tokens are sensitive credentials and must be handled like passwords or API keys. The raw token is shown to you exactly once at generation time — copy it immediately into your IdP's SCIM configuration or a secret manager. If you lose a token, generate a new one and revoke the old one.
Tokens are stored as HMAC-SHA-256 digests using a server-side key. The raw credential is not retained and cannot be displayed again after creation.
We recommend creating separate named tokens per IdP environment — for
example entra-prod and entra-staging — so you can rotate or revoke
independently.
Audit logging
Every SCIM action is recorded in Scrydon's audit log:
- Token generation and revocation (with the org admin who performed the action)
- User provisioning, linking, updates, and deprovisioning
- Group creation, member additions, member removals, and deletion
- Any rejected SCIM calls (invalid token, email conflict, scale cap hit)
View the audit log in Settings → Platform → Audit Log. Filter on the
event prefix scim.* to see only SCIM-related entries. The full list of
events lives in the audit events catalogue.
Related
- Hard fencing — restrict system credentials to the workspace's members via an IdP security group.
- SCIM operations — runbooks for scale caps, throttling, drift, and rotation.
- Audit events catalogue — every event the platform emits.