Claude SSO and SCIM: the setup that holds

TL;DR

Claude SSO works on Team and Enterprise, but SCIM directory sync is Enterprise only. SCIM is the only mode that removes leavers automatically. The single most common failure is an email attribute that differs between the SCIM connector and the SAML assertion, which produces login errors nobody can trace from inside Claude.

Which provisioning mode fits your plan

Claude controls how members join through one setting in identity and access settings, and the choice is constrained by plan. Where that decision sits in a wider rollout is covered in our 90-day adoption plan. Anthropic’s provisioning documentation sets out three modes, with Invite only as the default.

Mode	Members added	Members removed	Role assignment	Available on
Invite only	Admins add them in Claude or Console settings. Signing in through SSO adds nobody	Manually	Manual	All plans
Just-in-time	Users assigned to the Claude app in your IdP, on first login	Manually only	User role, or the highest role from mapped groups. Changes apply at next login	Team, Enterprise, Console organizations
SCIM directory sync	Automatically from IdP assignment, no login needed	Automatically when unassigned in the IdP	Manual, unless group mappings are on	Enterprise plans and Console organizations with a parent or joined Enterprise organization

Two constraints follow from the table and they decide your plan, not your budget. SCIM is not available for Team plans or for Console organizations joined to a Team plan’s parent organization. Custom roles are Enterprise only. If automated joiner and leaver handling is a control your auditors expect, Team is not a candidate.

SSO itself is broader. It works on Team, Enterprise and Console organizations, and Console organizations need a parent organization.

What SCIM controls and what stays manual in Claude

SCIM handles membership. It does not handle everything, and teams that assume it does end up with an orphaned permission model.

What the directory drives:

1. Adding a member when they are assigned to the Claude application in your IdP.
2. Removing a member when that assignment is withdrawn.
3. Group membership, which Claude can map to roles when group mappings are turned on.

What stays inside Claude:

1. Roles and seat types, unless group mappings are explicitly configured.
2. Spend limits, which resolve per member from group, seat tier and organization defaults, as our AI FinOps guide explains.
3. Model entitlements, meaning which models a role may use and which model new conversations start with.
4. Data retention settings and the Compliance API configuration.

That split matters for the design review. SCIM gives you the lifecycle; it gives you none of the authorization. If your control objective is “no leaver retains access”, SCIM answers it. If the objective is “no one in finance can use the most expensive model”, the answer sits in group-based model entitlements, which the analytics dashboard can then filter by the same SCIM groups. Our governance framework guide maps those controls onto the usual policy headings.

The email attribute that breaks every second rollout

One configuration error causes most SSO support tickets, and it is the same error on every identity provider: the field used for SCIM email and the field used in the SAML email claim are not the same field.

Anthropic’s Entra ID guide states plainly that the attribute used for SCIM email and SSO email must be identical, and calls a mismatch “the most common cause of login failures”. The Okta guide names the specific pairing that catches people: SCIM reading user.login while SAML reads user.email. These are identical for most users and different for exactly the users who were renamed, married, or migrated from a legacy domain.

The symptom is misleading. Provisioning succeeds, the member appears in Claude, and then the sign-in fails. Nothing in the Claude admin console points at the IdP.

Per-provider configuration worth writing down before you start:

Setting	Okta	Microsoft Entra ID
Name ID format	EmailAddress	From the WorkOS flow
Email claim	Attribute named email mapped to user.email	Email claim sends user.mail, or whichever attribute SCIM will use
SCIM email mapping	The same Okta field as the SAML claim	Under Mappings, pointed at the same field, typically user.mail
Group claim for role mapping	Group attribute statement named groups	Assign people and groups under Users and groups
Licence requirement	Okta administrator access	Entra ID P1 or P2 for SCIM provisioning
Claude role needed	Owner or Primary Owner (Team, Enterprise) or Admin (Console)	Same, plus Global Administrator or Application Administrator in Entra

The Entra licence line is the one that derails procurement. SCIM provisioning requires Entra ID P1 or P2. An organization on a lower tier has to buy identity licences before it can automate Claude membership, and that cost belongs in the business case rather than in a surprise mid-rollout.

Group mappings, roles and the JIT removal trap

Group mappings are available with both just-in-time and SCIM. They are also where the sharpest edge lives.

With just-in-time provisioning and group mappings on, a user whose sign-in carries no mapped group is removed from the organization at their next login. Read that again before you enable it. A SAML assertion that silently stops carrying the groups attribute, because someone edited the Okta app or the group was renamed, does not cause an error. It deprovisions people one login at a time.

Without the group attribute statement, sign-ins carry no group data at all, so role assignment fails and users land with the base User role. Under just-in-time, a user joins with the User role or with the highest role from their mapped groups, and role changes take effect at the next login rather than immediately.

Two practical rules:

1. Turn on group mappings only after you have confirmed the group claim arrives, with a test account in a mapped group and a second test account deliberately outside every mapped group.
2. On SCIM, prefer manual role assignment for Owners and Admins. Group-driven elevation is convenient and it means a change in an IdP group grants administrative access to Claude without anyone in your organization approving it in Claude.

What the GDPR asks of your identity design

Two obligations land squarely on this configuration.

Deletion and the leaver gap. Under the GDPR you need to be able to stop processing a former employee’s data and to show when access ended. Invite only and just-in-time both leave removal as a manual ticket, so the control is a human remembering. SCIM closes that gap structurally, which is the argument that usually wins the Enterprise plan discussion. For the retention side, see our Compliance API guide, which covers what the activity logs and chat history exports actually contain.

Works councils and monitoring. In Germany, per-user usage and cost reporting plus audit logs are performance monitoring in the sense of section 87(1)6 of the Works Constitution Act, so the works council has a co-determination right over the configuration, not just an information right. Bring the group design and the analytics configuration to that conversation early, because retrofitting a group model after an agreement is signed is expensive.

Processor obligations. The data processing agreement and the residency route are separate from identity, and they do not become less important because SSO is clean. Our data residency guide covers which routes actually keep inference in a given region and what each costs.

Run it yourself or outsource?

Task	Keep in-house	Sensible to outsource
SAML and SCIM configuration	Yes. Your identity team owns the IdP	A paired first connection, if it is your first WorkOS-based integration
Attribute mapping decision	Yes. Only you know which field is authoritative for your users	No
Group and role model	Yes. It mirrors the org chart and the works council agreement	Review of the first draft
Entra or Okta licence uplift	Procurement decision, in-house	No
Audit evidence and retention design	Yes, with legal	Template and gap review

Identity is the wrong thing to outsource permanently. Buying one paired session for the first connection is reasonable; handing over the attribute decision is not, because the authoritative email field is a fact about your directory that an external team has to guess.

FAQ

What does Claude SSO cost?

SSO itself carries no separate charge; it comes with Team and Enterprise plans. The costs are indirect: Claude Enterprise at 20 USD per seat per month billed annually with a 20-seat minimum if you need SCIM, plus an Entra ID P1 or P2 licence per user if your IdP is Entra and you are on a lower tier. For 50 users that is 12,000 USD a year for Claude before usage, plus the identity licences.

SSO vs SCIM: what is the difference for Claude?

SSO authenticates a member who already exists in your Claude organization. SCIM creates and removes that member from your directory. You can run SSO without SCIM, in which case membership is manual or just-in-time. You cannot run SCIM without SSO, because the directory connection sits on top of a configured identity provider.

Can we use SCIM on the Claude Team plan?

No. SCIM is not available for Team plans or for Console organizations joined to a Team plan’s parent organization. Team plan organizations use just-in-time provisioning instead, which adds members on first login and never removes them automatically. See our Team plan guide for the rest of the ceiling.

Which identity providers does Claude support?

Claude’s SSO and SCIM run through a WorkOS-based setup flow, and Anthropic publishes provider guides for Okta, Microsoft Entra ID, Google Workspace and OneLogin. The configuration values you need, including the entity ID, reply URL, SCIM tenant URL and secret token, come from that flow rather than from a static documentation page.

Why can users not log in after we turned on SCIM?

Almost always the email attribute. Check that the field SCIM writes as email and the field the SAML assertion sends as email are the same field in your IdP. On Okta the classic mismatch is user.login against user.email; on Entra it is any claim other than the one the SCIM mapping uses.

Does SCIM remove a member’s chat history when it removes them?

No. Removing a member ends their access; it does not delete the content they created. Retention of conversations and files is a separate setting, available with custom data retention on Enterprise, and the Compliance API is how you export or review that content before it ages out.

Sources

1. Anthropic: Setting up JIT or SCIM provisioning (28 October 2026)
2. Anthropic: SSO setup with Okta (28 October 2026)
3. Anthropic: SSO setup with Microsoft Entra ID (28 October 2026)
4. Anthropic: Claude pricing plans (28 October 2026)
5. Anthropic: Giving admins more visibility and control over Claude spend (28 October 2026)