SCIM security

RFC 7642 contains exactly one MUST-level security requirement: "data confidentiality MUST be guaranteed at the transport layer" (RFC 7642 Section 4, retrieved 2026-11-01). RFC 7644 Section 7 carries the rest of the baseline. Section 7.2 requires TLS; Section 7.3 defines no SCIM-specific authentication scheme and requires the service provider to map the authenticated client to an access-control policy; Section 7.4 covers bearer tokens and cookies, with the service provider advertising its schemes viaWWW-Authenticate.

The section with the most operational consequence is 7.5.2, sensitive data in URIs. List requests carry filters in the query string, and intermediaries log URLs: load balancers, proxies, and access logs all seefilter=userName eq "[email protected]" (and anything more personal a filter expresses). The RFC's own example returns the sensitive scimType with 403 when a provider declines to process sensitive data in a URI; the erratum that fixed the example's status field (6893, verified 2022-03-25) is itself a reminder that the security sections get edited like any other. The mitigation is in the protocol already: POST search at /.search (or [prefix]/.search) carries the same SearchRequest body without the URI exposure (RFC 7644 Sections 3.4.3 and 7.5.2). A deployment that logs full query strings should prefer POST search for filters on personal attributes.

SCIM inherits its token mechanics from OAuth; this page does not re-teach them. Bearer token usage (RFC 6750), sender-constrained tokens with DPoP (RFC 9449), and the broader framework (RFC 6749) are taught in the oauth2 lab-site, with per-RFC breakdowns:RFC 6750, bearer token usage andRFC 9449, DPoP. The SCIM-specific duty on top of them is 7644 Section 2's: whatever the scheme, the service provider MUST map the authenticated client to an access-control policy, and a credential scoped for provisioning should be able to do nothing else.

Cursor pagination (RFC 9865, October 2025) adds a capability token-shaped object to list responses: the cursor string. Its security considerations (RFC 9865 Section 7, retrieved 2026-11-01) assign the properties an implementer has to build:

Possession of a cursor confers no privilege. Authorization is re-checked on every page, so a leaked cursor grants a replay of pages the holder was already allowed to see, never new scope. When a user's permissions change, the service provider SHOULD invalidate that user's outstanding cursors or keep page counts consistent, so a permission revocation cannot be walked around with a cursor issued before it. Cursors SHOULD be obfuscated or forgery-detectable rather than raw offsets, so clients cannot manufacture page keys. The anti-probing rule is a MUST: error responses for an out-of-scope page and a nonexistent page MUST be identical, because a difference tells the caller which page keys exist (admin logs MAY differ). The availability guidance treats large queries as a cost center: rate limiting per RFC 6585, ceilings on live cursors, a maxPageSize, and the option to answer anonymous large queries with 400 tooMany.

Provisioning events as Security Event Tokens (RFC 9967, May 2026) reverse the data flow, and its security considerations (Section 8, retrieved 2026-11-01) follow the reversal. Transport: TLS is REQUIRED for sensitive SETs. Delivery: a receiver MUST persist an event before acknowledging it, because the acknowledgment is the publisher's signal to stop redelivering; an ack-then-crash loses the event. Signing: JWS signature verification is REQUIRED when the publisher is not communicating directly with the receiver, which is also the case that matters in practice, since the signature protects the payload through TLS-terminating proxies that decrypt and re-encrypt. The asynchronous-request completion URI MUST require authentication; RFC 9967's guidance for high-churn groups (the 100k-member case) is to prefer PATCH over PUT, use notice events plus periodic GETs rather than full-data events, and aggregate PATCHes, because PUT on a huge group floods every payload with the full member list.

One conflict in the published text is still unresolved, and it sits on the most sensitive attribute in the schema. RFC 7643 Section 4.1.1 defines password as write-only and never returnable, and its security section (9.2) expects the value to arrive pre-hashed or encrypted. The Section 8.7.1 schema example, though, marks password with caseExact: false. Case-insensitive equality is the wrong contract for a salted hash: two hash computations over inputs differing only in case produce different digests, and RFC 7644 Section 5's preparation rules (the RFC 8265 OpaqueString profile) preserve case for exactly this reason. Erratum 9190 flags the contradiction; it stands as Reported, not Verified, as of 2026-11-01, and the RFC-revision work in the working group is where its resolution lives.

The lesson generalizes beyond passwords. The Section 8 examples are normative-by-example, and errata against them are corrections to normative text, not typos; a schema built by copying the published JSON inherits its defects wholesale. This lab-site's schema explorer ships the 2025-10-28 corrected schema as its default, with the as-published variants one toggle away, and the RFC 7643 breakdown page carries the per-errata detail.