SCIM: Group.members is returned: request, is this behavior intended? #54267

MaximilianClemens · 2026-10-22T13:30:45Z

MaximilianClemens
Oct 22, 2026

Description

PR #47636 (Keycloak 26.6) introduced that Group#members (and User#groups) are only returned when explicitly requested. The published schema marks the attribute as "returned": "request" accordingly. The rationale in the PR was to avoid fetching all memberships.

RFC 7643 specifies "returned": "default" for attributes unless stated otherwise (§2.2), and the Group schema representation in §8.7.1 also lists members with default. At the same time, request is a valid value per §7, and RFC 7644 §3.4.2.5 allows clients to explicitly request attributes via the attributes parameter.

Background

We run Keycloak as a central SSO platform and received feedback from a customer and a software vendor that the vendor's SCIM client imports groups from Keycloak without members. The client currently does not evaluate the published schema at /Schemas and assumes the default value default. We have suggested to the vendor to evaluate the schema and request members explicitly where needed.

Steps to reproduce (Keycloak 26.8.0)

Realm with SCIM API enabled, group with two members
GET /realms/{realm}/scim/v2/Schemas/urn:ietf:params:scim:schemas:core:2.0:Group returns "returned": "request" for members
GET /realms/{realm}/scim/v2/Groups/{id} returns the group without members
GET /realms/{realm}/scim/v2/Groups/{id}?attributes=displayName,members returns both members

Questions

Is this behavior intended and meant to stay this way?
Would it make sense to make this configurable (e.g. per realm, or per SCIM client) to improve compatibility with clients that assume the default? A per-client setting might fit better, since different integrations in the same realm may behave differently.
Or is the recommended position that clients should evaluate the published schema at /Schemas? In that case we would communicate this accordingly to vendors.

References

PR Support for managing members via group resource type #47636: Support for managing members via group resource type
RFC 7643 §2.2, §7, §8.7.1
RFC 7644 §3.4.2.5

Disclosure: AI assistance

This post was researched and drafted with the help of an AI assistant (Claude by Anthropic). The workflow was roughly:

"A vendor tells us Keycloak cannot be fully used as a source for user and group sync via SCIM, because members is returned: request instead of default per RFC 7643. Is that a fact, and does Keycloak deviate from the standard?"
"Check this statement against the RFC and test it." (The AI set up a fresh Keycloak 26.8.0 instance, enabled the SCIM API and ran the requests listed under "Steps to reproduce".)
"Check whether there are already issues about this, especially ones that consider the behavior non-compliant." (No existing issue was found; Support for managing members via group resource type #47636 was identified as the origin.)
"Write a neutral question referencing Support for managing members via group resource type #47636, without asking for a change."

I have reviewed the content and the RFC references. Please let me know if anything is inaccurate.

Regards
MaximilianClemens

Navigation Menu

Repository navigation

SCIM: Group.members is returned: request, is this behavior intended? #54267

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

SCIM: Group.members is returned: request, is this behavior intended? #54267

Uh oh!

MaximilianClemens Oct 22, 2026

Replies: 0 comments

MaximilianClemens
Oct 22, 2026