Keycloak Native SCIM API Preview in 26.7: What It Covers, What It Misses, and When Managed Still Wins

Update, October 2026: Keycloak 26.8.0 promoted the SCIM API to supported and enabled the scim-api feature by default, though each realm still needs its own SCIM API toggle (which, correcting what we say further down, already existed in 26.7). Bracket filters on name and groups.value or members.value lookups work; the failing case is emails[type eq "work"]. See Keycloak 26.8 SCIM API: supported and on by default for the current state.

Keycloak 26.7 promotes the native SCIM API from experimental to preview behind the scim-api feature flag, and it is disabled by default. The implementation covers full CRUD and PATCH on users and groups, filtering, pagination, schema discovery and the Enterprise User extension, which is enough for Entra ID or Okta to push users into a Keycloak realm. It does not cover bulk operations, sorting, or valuePath bracket filters, all three of which are confirmed open gaps in the upstream tracker. It is also inbound only: what 26.7 ships is Keycloak acting as the SCIM service provider, so Keycloak can receive a directory push but has no outbound SCIM client to push users anywhere else.

The short answer for most teams is that the preview is genuinely usable as an identity sink and genuinely not ready to be the only thing between your HR system and production. Here is where each line falls.

Does Keycloak support SCIM natively now?

Keycloak supports SCIM natively as of 26.7, but as a preview feature rather than a supported one. Keycloak 26.7.0, released on 9 July 2026, promoted the SCIM API from experimental to preview. Per the release notes for 26.7.0, “Keycloak has SCIM APIs for managing users and groups within a realm. The implementation covers full CRUD and PATCH operations, filtering and pagination, schema extensions including the Enterprise User extension, and schema discovery endpoints.”

The path to this point started earlier in 2026: Keycloak published “SCIM Realm API as an Experimental Feature” in April 2026, and 26.7 is the promotion of that work one rung up the maturity ladder. The practical meaning of the preview label, per the 26.7.0 release notes, is that the feature is disabled by default in the default profile and has to be switched on deliberately. Preview features also sit outside the compatibility commitments that apply to supported ones, which is what makes the next paragraph the part to plan around.

That last part is the operational catch, and it matters more than the feature list. A preview API can change shape in 26.8 in ways a supported API cannot. If an external identity provider is pushing your production users through it, a Keycloak upgrade becomes a provisioning-integration test rather than a routine patch.

Our read: the interesting thing about this release is not that Keycloak gained SCIM, it is that Keycloak gained the inbound half of SCIM. Most teams asking “does Keycloak support SCIM” are actually asking one of two completely different questions, and the answer differs by question. If you want Okta to provision users into Keycloak, 26.7 is your answer. If you want Keycloak to provision users into Salesforce, 26.7 does nothing for you at all, and no amount of enabling the flag will change that.

What does the native SCIM API actually cover?

It covers the operations an external identity provider needs to keep a user directory in sync, addressed per realm under the realm’s SCIM 2.0 base path.

Concretely, what is in the box:

• Users and Groups resources with create, read, update, delete and PATCH
• Filtering and pagination on list operations
• Schema discovery endpoints, so a client can ask what the server supports rather than guessing
• The Enterprise User extension, which carries the fields HR systems care about, such as employee number, department and manager

That set is the core of SCIM 2.0 as the protocol defines it, and it is a credible implementation rather than a stub. An Entra ID or Okta provisioning connector pointed at a Keycloak realm can create users, update their attributes, add them to groups and deactivate them on departure.

What the release notes describe is user and group records rather than credential material, and that split is the right one. Passwords stay with whichever system owns authentication instead of being copied across a provisioning channel. If your current design relies on SCIM to move password material, that is worth revisiting regardless of which implementation you land on.

What is still missing from the preview?

Three RFC 7644 features are confirmed missing, and one of them will bite at scale. Keycloak’s own issue tracker carries an open report, issue 50366, titled “SCIM RFC 7644 gaps: Bulk Operations unsupported + valuePath bracket filters (e.g. emails[type eq "work"]) return no results + Sorting not supported.”

Bulk operations are not supported. The ServiceProviderConfig endpoint reports bulk.supported: false, and a POST to the Bulk endpoint with a valid BulkRequest does not return a BulkResponse. The practical consequence is arithmetic: without bulk, an initial directory push of ten thousand users is ten thousand separate HTTP requests, each with its own round trip and its own database write. That is survivable for a few hundred users and unpleasant for a large workforce migration.

Sorting is not supported. ServiceProviderConfig reports sort.supported: false, so sortBy and sortOrder are ignored. Most provisioning connectors do not depend on sort, so this is the least painful of the three.

valuePath bracket filters return nothing. A filter such as emails[type eq "work"] returns zero results even when matching users exist. Filtering is otherwise reported as supported, which makes this the sharp edge: the server advertises filter support, the specific filter syntax fails silently with an empty result set rather than an error, and a connector written against the spec will conclude there are no matching users. That failure mode is worth planning around, because a provisioning run that quietly syncs nobody looks identical to a provisioning run that had nobody to sync.

The issue was still open as of September 2026, labelled as a feature request awaiting implementation, and the reporter’s framing is that these block enterprise provisioning flows with Entra ID and Okta specifically.

Should I use the native preview or a SCIM extension?

Use the native preview if you are evaluating, and keep an extension or a managed path if directory sync is already load-bearing in production.

The honest summary is that the native API trades one kind of operational cost for another. It removes a deployed extension from your stack, which is a real win, and replaces it with an upgrade-coupling risk that lasts until the feature goes supported.

If you are already running the Skycloak SCIM path, our guide to using SCIM 2.0 with Skycloak managed Keycloak covers that setup, and it does not change because of 26.7. If you are wiring Okta specifically, SCIM integration between Okta and Keycloak walks the connector side.

How do I turn it on and test it safely?

Enable the feature flag, then exercise the endpoints against a non-production realm before pointing a real identity provider at it.

The steps that matter:

1. Start the server with the scim-api feature enabled. It is off in the default profile, so this is an explicit opt-in at the server level. The API is then addressed per realm.
2. Give the calling identity a service account with the right admin roles. SCIM writes are admin operations underneath, so the permissions model is the Admin API’s rather than a dedicated SCIM permission set. Scope that service account to exactly the realm it provisions and nothing else.
3. Fetch ServiceProviderConfig first. It tells you what this build actually supports rather than what the spec says. This is where you will see bulk.supported: false and sort.supported: false for yourself instead of taking a blog post’s word for it.
4. Test your connector’s real filter syntax. Given the valuePath gap, run the exact filters your identity provider emits and check that non-empty result sets come back. An empty response is the failure mode here, not an error code.
5. Check the reverse-proxy path. The SCIM endpoints sit under the realm path, so any proxy rule that allowlists specific Keycloak paths needs updating before the connector can reach them.
6. Re-run the whole set after every Keycloak upgrade while the feature is in preview. That is the cost of the preview label, and building the test once makes it cheap.

If you want a harness for step four, building and testing a SCIM API endpoint covers the request shapes to exercise.

Our read: step three is the one teams skip, and it is the cheapest insurance in the list. ServiceProviderConfig is a single unauthenticated-shaped GET that tells you the truth about the build in front of you. In most of the “SCIM is broken” threads we have seen on a preview feature, the behaviour being reported as a bug was already declared unsupported in that document.

What does this mean for multi-tenant B2B provisioning?

It means the hard part is still yours to build. The native API provisions users and groups into a realm, and a realm is the natural tenant boundary in Keycloak, so a hundred customers provisioning into your platform means a hundred realms each with its own SCIM endpoint and its own service account.

Two details make that shape more awkward than it first looks. The feature flag is a server-level setting rather than a per-realm one, so enabling SCIM for one tenant enables the capability across the whole server, and whether a given realm actually accepts SCIM traffic becomes a matter of credentials and proxy rules rather than of the flag. And because SCIM writes authenticate as admin operations, each tenant’s connector needs a service account scoped tightly to its own realm, since the permissions model here is the Admin API’s rather than a dedicated SCIM permission set.

Neither is a blocker, and both are recurring work the preview does not do for you: credentials issued and rotated per tenant, a proxy path opened per realm, and monitoring on each connector so a silently failing sync does not surface as a support ticket three weeks later.

Keycloak’s organizations feature covers some multi-tenancy within a single realm, but the SCIM preview’s resources are Users and Groups rather than organization-scoped endpoints, so the per-tenant-realm shape remains the straightforward one as of 26.7.

When does managed Keycloak still win?

When the flag, the upgrade coupling and the per-tenant plumbing are work you would rather not own.

Skycloak is identity management as a service built on upstream Keycloak, so the native SCIM API is the same native SCIM API, and our SCIM feature page describes the provisioning surface we support around it. What changes is who carries the preview-feature risk: enabling the flag, re-testing provisioning after each upgrade, and keeping an eye on whether the bulk and filter gaps have closed upstream. For a team running one realm with a few hundred users, that overhead is small enough to absorb. For a team running provisioning for dozens of tenants, it is a recurring tax, and it is the kind of thing we went through in is self-hosting Keycloak worth it in 2026.

The provider landscape, including who supports what on provisioning, is in managed Keycloak providers compared.

FAQ

Does Keycloak support SCIM?
Yes, natively since 26.7 as a preview feature behind the scim-api flag, disabled by default. It supports CRUD, PATCH, filtering, pagination, schema discovery and the Enterprise User extension for users and groups. Bulk operations, sorting and valuePath bracket filters are not supported.

Is Keycloak’s SCIM API inbound or outbound?
Inbound. Keycloak acts as the SCIM service provider, receiving users and groups from an external system such as Entra ID, Okta or an HR platform. There is no outbound SCIM client in 26.7, so Keycloak cannot provision users into third-party applications using this API.

Can I use the native SCIM API in production?
You can, but preview features carry no compatibility guarantee and can change between minor releases. If you do, pin your Keycloak version deliberately, test the provisioning path on every upgrade, and be aware that an initial sync of a large directory will be slow without bulk support.

What is the difference between SCIM and SSO in Keycloak?
SSO handles authentication, letting a user prove who they are once and reach many applications. SCIM handles provisioning, creating and deactivating the account records themselves before anyone signs in. You generally need both, and we compare SCIM against SAML directly for teams sorting out which does what.

How many requests does an initial SCIM sync take?
One per user, because bulk is unsupported and ServiceProviderConfig reports bulk.supported: false. A ten thousand user directory is ten thousand requests. Plan the initial load as a scheduled operation rather than something you run during business hours.

Sources

• Keycloak, release 26.7.0 notes, 9 July 2026, retrieved 2026-09-12, https://github.com/keycloak/keycloak/releases/tag/26.7.0
• Keycloak, issue 50366, “SCIM RFC 7644 gaps: Bulk Operations unsupported + valuePath bracket filters + Sorting not supported,” open as of September 2026, retrieved 2026-09-12, https://github.com/keycloak/keycloak/issues/50366
• Keycloak, “SCIM Realm API as an Experimental Feature,” April 2026, https://www.keycloak.org/2026/04/scim-as-experimental-feature
• IETF, “System for Cross-domain Identity Management: Protocol” (RFC 7644), https://datatracker.ietf.org/doc/html/rfc7644