Keycloak 26.8 SCIM API: Supported and On by Default

Keycloak 26.8.0, tagged on 1 October 2026, promotes the native SCIM API from preview to supported and enables the scim-api feature by default, so you no longer start the server with --features=scim-api. Each realm still has to opt in through the “SCIM API” toggle under Realm settings, and the API is still inbound only: Keycloak receives users and groups from Entra ID, Okta or an HR system, but it does not push users anywhere else. Bulk operations, sorting, ETags and password changes remain unsupported.

If you read our post on the 26.7 preview, most of what it described still holds, but three things have moved: the maturity label, the default state of the feature, and the documented limits. One correction to that post as well: the per-realm SCIM toggle already existed in 26.7, so realm-level opt-in is not new in 26.8. This post walks through each change, what it means for a provisioning connector already pointed at Keycloak, and what you should check before and after the upgrade.

What changed for Keycloak SCIM in 26.8?

The headline change is the support level. The Keycloak 26.8.0 release notes, published in October 2026, say that “the SCIM API is promoted from preview to supported” and list it among the release highlights as a way to “automate user provisioning across identity systems”. Supported means the feature now carries the same compatibility expectations as the rest of the server, rather than the preview caveat, which the Keycloak features guide words as “not recommended for use in production” and liable to “change or be removed at a future release”.

The release notes also list four areas of improvement:

• Multivalued user attributes. A user profile attribute marked as multivalued can now be exposed through SCIM, either as a flat array of strings or as an array of {"value": ...} objects, and you can filter on it.
• User Profile permissions. SCIM now follows the same admin view and edit permissions as the Admin REST API, so a custom (mapped) attribute without admin view permission is invisible to SCIM, and one without admin edit permission is treated as read-only. Core attributes such as userName and name.givenName stay readable and writable regardless.
• Fine-Grained Admin Permissions (FGAP) in search filters. FGAP is Keycloak’s per-resource admin permission model, and it now applies to SCIM search results, which affects how membership filters behave (more on that below).
• Performance for large user bases. The release notes state this qualitatively and do not publish figures, so treat it as a reason to re-measure your own initial sync rather than as a number to plan around.

The second change is in the upgrading guide. Its 26.8.0 entry, “SCIM API is now enabled by default”, says the feature “has been promoted from preview to supported and is now enabled by default. If you previously enabled this feature explicitly with --features=scim-api or --features=preview, that configuration is no longer required.” You can leave the old flag in place without harm, but it no longer does anything you need.

Is the SCIM API enabled automatically after upgrading to 26.8?

At the server level, yes; at the realm level, no. The upgrading guide for 26.8.0 confirms the scim-api feature is on by default, and the server administration guide still says that “once the feature is enabled on the server, you must also enable SCIM for each realm individually”, through the Admin Console or the Admin REST API.

In the Admin Console the switch lives under Realm settings, on the General tab, as the SCIM API toggle. Until you turn it on and save, the realm does not serve SCIM traffic, even though the server has the capability loaded. That two-level design is what makes the default-on change reasonable, but it also changes the shape of your security review.

What is the security implication of default-on?

Before 26.8, a server without the scim-api flag could not expose SCIM at all, so “is SCIM on?” was a question about one startup option. Now the capability is present on every 26.8 server, and exposure depends on which realms have the toggle on and which clients can obtain tokens with the right roles. We’d suggest treating the upgrade as a prompt for a short audit:

1. List the realms with the SCIM API toggle on, and confirm each one is intentional. A realm someone switched on during a test is now a supported, production-grade endpoint.
2. List the service accounts holding realm-management roles such as manage-users, view-users, query-users and query-groups. The SCIM API uses the same permission model as the Admin REST API, so the guide says a service account that already holds those admin roles needs no extra roles for SCIM. The realm toggle and an audience mapper are still required, as covered below.
3. Check your reverse proxy rules. The endpoints live under /realms/<realm>/scim/v2, so if you publish only specific Keycloak paths, decide deliberately whether that path should be reachable from outside.

If you do not want the capability on the server at all, the Keycloak features guide documents kc.sh build --features-disabled=scim-api (or --feature-scim-api=disabled). It is a build option, so it needs a rebuild or a non-optimized start. For most teams, leaving the feature on and controlling the realm toggle is the simpler policy, because it keeps the decision next to the realm it affects.

What did 26.8 clarify about Keycloak SCIM filtering?

No filter gap from the 26.7 preview was closed, but the limits are now written down. Value path filters on name (for example name[familyName eq "Smith"]) and membership lookups such as groups.value eq and members.value eq were already documented and working in 26.7, and the filter grammar is unchanged between the 26.7.5 and 26.8.0 tags. What 26.8 adds to the server administration guide is an explicit list of constraints, rules for null and missing values, and the FGAP restriction on membership filters.

The case from the 26.7 post still fails. Upstream issue 50366 reported that emails[type eq "work"] returns no results, and in the 26.8.0 source the emails attribute has no filterable type sub-attribute, so the filter is logged as unresolvable and matches nothing rather than returning an error. The 26.8 guide also dropped its earlier PATCH example that used emails[type eq "work"]. Connectors that look users up should filter on userName or on emails directly (the guide’s example is emails eq "[email protected]") instead.

The guide documents the RFC 7644 comparison operators (eq, ne, co, sw, ew, gt, ge, lt, le and pr) and the and, or and not logical operators. For PATCH requests, removing specific members with a bracket path such as members[value eq "{userId1}" or value eq "{userId2}"] is documented too.

There are documented limits that a connector author should know about:

What is still not supported in Keycloak SCIM?

Four optional RFC 7644 capabilities remain off, and the ServiceProviderConfig endpoint reports each one as "supported": false. The 26.8 server administration guide lists them explicitly as not supported in this release.

• Bulk operations. There is no /Bulk endpoint, so you send one request per resource. An initial load of a large directory is one HTTP request per user, which is something to schedule rather than run at peak hours.
• Sorting. sortBy and sortOrder are accepted but ignored, and results come back in the default order of the underlying store, which matches the Admin REST API.
• ETags and resource versioning. Resources do not carry meta.version, and conditional requests with If-Match are not honoured, so there is no optimistic concurrency check: a connector cannot ask Keycloak to reject its write if the resource changed since it last read it.
• Password changes. The password attribute cannot be set or updated through SCIM. The guide points you to the Admin Console or Admin REST API for credentials.

A few attribute-level limits also carry over. emails is multivalued in SCIM but backed by Keycloak’s single email attribute, so only the first value is stored. The addresses attribute is not supported, and phoneNumbers, entitlements, roles and similar core attributes cannot be mapped under the core schema URN, although you can expose equivalent data through a schema extension. Users held only in an LDAP or custom federation provider, and never imported, do not appear in SCIM results.

Does Keycloak SCIM do outbound provisioning in 26.8?

No. The 26.8 documentation describes Keycloak only as the SCIM service provider at /realms/<realm>/scim/v2, receiving requests from external systems. The Keycloak server does not push users or groups to other applications over SCIM. The 26.8.0 source tree does include a SCIM client library module, but only Keycloak’s test framework depends on it and it is not a provisioning feature you can configure, so if you need Keycloak to provision into Salesforce or another SaaS application, you still need an extension or a separate provisioning tool.

How do I set up a Keycloak SCIM client for a provisioning connector?

The setup is the same as in 26.7, and the 26.8 guide spells it out more fully. You create a confidential client with a service account, grant it realm-management roles, and make sure its access tokens carry the SCIM base URL as their audience. Only confidential clients can call the SCIM endpoints, and tokens without the right audience get 401 Unauthorized.

The steps from the server administration guide, in short:

1. Create a client (for example scim-client) with Client authentication and Service accounts roles enabled, and note the secret.
2. In the dedicated client scope, set Full Scope Allowed to Off. The guide warns that this switch is deprecated and should not be enabled on the SCIM client.
3. Add the realm-management roles you need as role scope mappings on that dedicated scope, and assign the same roles to the service account. The token only carries the intersection of the two, so both steps are required.
4. Add an Audience mapper whose custom audience is the realm’s SCIM base URL, matching scheme, host, port and path exactly as Keycloak sees them. Behind a reverse proxy, that means the frontend URL from your hostname settings.

For full access, manage-users covers user and group writes plus the discovery endpoints. A read-only reporting integration can get by with view-users and query-users, plus query-groups if it also lists groups. The token request itself is a normal client credentials grant:

curl -s -X POST https://<host>/realms/<realm>/protocol/openid-connect/token 
  -d grant_type=client_credentials 
  -d client_id=scim-client 
  -d client_secret=<secret>

On the Entra ID or Okta side, the connector needs the realm’s SCIM base URL and a way to present that bearer token, and where you enter those depends on how the provisioning app is configured there. For the Okta half in more detail, see SCIM integration between Okta and Keycloak.

How are admin accounts protected from SCIM?

Keycloak treats any user or group holding an administrative role (from realm-management, the master realm admin clients, or master realm roles such as admin) as protected. Through SCIM, reads return only id, schemas and userName (or displayName for groups), and PUT, PATCH and DELETE return 403 Forbidden. Adding a user to an admin group from either side is blocked too, as is deleting a parent group whose subtree contains an admin group.

This protection exists because SCIM clients usually hold broad management permissions, and the guide’s reasoning is that a compromised or misconfigured connector should not be able to lock out realm administrators or escalate someone into an admin group.

What should I re-test in my provisioning connector after upgrading?

Plan for a short regression pass even though the API is now supported, because a connector configured against the 26.7 preview may be relying on behaviour the docs now define more precisely. We’d keep the checklist close to what the 26.8 documentation actually states:

• Check that the realm toggle is on in every realm your connector provisions into, especially after restoring or importing realms.
• Check that tokens carry the SCIM audience. If you moved Keycloak behind a new hostname, the audience mapper value has to change with it, or every call returns 401.
• Check the filters your connector sends. Lookups like userName eq "..." are the common case; capture the exact filter strings from your connector’s logs and run them against a test realm, and replace any emails[type eq ...] filter with a userName or plain emails eq filter.
• Check pagination. The connector must page with startIndex and count, because any request is capped at 100 results.
• Check that nothing sends a password. changePassword is unsupported, so a connector configured to sync passwords needs that mapping removed.
• Check how admin accounts show up. If your connector tries to update or deactivate an account that holds an admin role, expect 403, and decide whether that account should be managed outside SCIM.
• Check multivalued and extension attribute mappings. Any attribute your connector sends beyond the core set needs a User Profile attribute with a SCIM mapping, admin view permission to be visible and admin edit permission to be writable. Without edit permission, writes are silently ignored rather than rejected.
• Check membership filters if FGAP is on. With fine-grained admin permissions enabled, only eq works on groups.value and members.value; other operators, and negated equality, return empty results instead of an error.

Two quick calls are useful here, and our SCIM endpoint tester will build the curl commands and validate the SCIM JSON you send. A GET on /ServiceProviderConfig tells you what the running build supports, and a GET on /Schemas shows which extension attributes the realm currently exposes. If you want to script these checks, building and testing a SCIM API endpoint covers the request shapes, and our upgrade strategy guide covers how to stage the upgrade itself.

How does the SCIM API fit multi-tenant B2B provisioning?

Multi-tenant provisioning in Keycloak SCIM is still per realm. Each realm has its own base URL at /realms/<realm>/scim/v2, its own toggle, and its own service account, so a platform where each customer has a realm gets one SCIM endpoint and one set of credentials per customer, which is a clean isolation boundary.

The 26.8 change makes this slightly easier operationally, because you no longer have to reason about a server-wide preview flag; each tenant’s exposure is decided by that tenant’s realm toggle and client. The per-tenant work remains: issuing and rotating a client secret per realm, setting the right audience on each, and monitoring each connector. If you use Keycloak organizations within a single realm instead, note that the guide says organization groups cannot have their members managed through SCIM: those requests return 400 Bad Request, and membership has to go through the Organization API. We cover the trade-offs between those two shapes in our multi-tenant authentication architecture guide.

What does this mean if you run managed Keycloak?

Skycloak is identity management as a service built on upstream Keycloak, so the native SCIM API on a Skycloak cluster is the same one described in the Keycloak documentation, with the same realm toggle, client setup and limits. Upgrades are where the 26.8 change shows up for you: the server-level flag is no longer something to track, but the realm toggles, audiences and connector re-tests above still apply to your realms. Our SCIM feature page describes the provisioning surface we support, and using SCIM 2.0 with Skycloak managed Keycloak covers the setup.

FAQ

Does Keycloak support SCIM?

Yes. Keycloak has a native SCIM 2.0 API at /realms/<realm>/scim/v2, and Keycloak 26.8.0, released in October 2026, made it supported and enabled by default at server level. Each realm opts in with its own toggle. It is inbound only, so Keycloak receives users and groups from systems such as Entra ID or Okta but does not push them elsewhere.

Is Keycloak’s SCIM API production-ready in 26.8?

Yes, in the sense that the Keycloak 26.8.0 release notes, published in October 2026, mark it as supported rather than preview. It covers CRUD and PATCH on users and groups, filtering, pagination, schema discovery and schema extensions. Bulk, sorting, ETags and password changes are still unsupported, so check those against your connector’s requirements first.

Do I still need –features=scim-api in Keycloak 26.8?

No. The 26.8.0 upgrading guide says the scim-api feature is enabled by default and the explicit flag is no longer required. You still have to switch on the SCIM API toggle under Realm settings, General, for each realm that should accept SCIM requests, so the server being on does not mean any realm is exposed.

Does Keycloak SCIM support bulk operations now?

No. In 26.8 the ServiceProviderConfig endpoint still reports bulk.supported as false, and there is no /Bulk endpoint. Your connector sends one request per user or group, and list requests return at most 100 results each, so a large initial sync takes many requests and is best scheduled outside peak hours.

Can Entra ID or Okta set user passwords through Keycloak SCIM?

No. changePassword is reported as unsupported, and the server administration guide says the password attribute cannot be set or updated through SCIM. Credentials stay with Keycloak and are managed through the Admin Console or Admin REST API, or users authenticate through a federated identity provider. If your connector maps passwords, remove that mapping.

What is the SCIM base URL for a Keycloak realm?

It is https://<host>/realms/<realm>/scim/v2, with /Users, /Groups, /ServiceProviderConfig, /ResourceTypes and /Schemas beneath it. The same URL has to appear as the audience in your service account’s access tokens, matching the frontend hostname exactly. For background on the protocol itself, see what SCIM is and why it matters, and for how it differs from single sign-on, SCIM vs SAML.

Sources

• Keycloak, Keycloak 26.8.0 release notes (source at tag 26.8.0), https://github.com/keycloak/keycloak/blob/26.8.0/docs/documentation/release_notes/topics/26_8_0.adoc (published version: https://www.keycloak.org/docs/latest/release_notes/index.html)
• Keycloak, Upgrading Guide, changes in 26.8.0, “SCIM API is now enabled by default” (source at tag 26.8.0), https://github.com/keycloak/keycloak/blob/26.8.0/docs/documentation/upgrading/topics/changes/changes-26_8_0.adoc
• Keycloak, Server Administration Guide, “Managing users and groups through SCIM” (source at tag 26.8.0), https://github.com/keycloak/keycloak/tree/26.8.0/docs/documentation/server_admin/topics/scim (published version: https://www.keycloak.org/docs/latest/server_admin/index.html#_managing_scim)
• Keycloak, Enabling and disabling features (server guide, source at tag 26.8.0), https://github.com/keycloak/keycloak/blob/26.8.0/docs/guides/server/features.adoc
• Keycloak, UserCoreModelSchema.java at tag 26.8.0 (SCIM user attribute model), https://github.com/keycloak/keycloak/blob/26.8.0/scim/model/src/main/java/org/keycloak/scim/model/user/UserCoreModelSchema.java
• Keycloak, issue 50366, “SCIM RFC 7644 gaps”, https://github.com/keycloak/keycloak/issues/50366
• IETF, RFC 7644, “System for Cross-domain Identity Management: Protocol”, 2015, https://datatracker.ietf.org/doc/html/rfc7644
• IETF, RFC 7643, “System for Cross-domain Identity Management: Core Schema”, 2015, https://datatracker.ietf.org/doc/html/rfc7643