SCIM服务端实现疑问：PATCH请求携带id属性是否合法？

作为服务提供商测试SCIM实现时，发现Okta和Jumpcloud发送的replace类型PATCH请求里会包含id属性，示例请求如下：

PATCH /Groups/3322
{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ],
    "Operations": [
        {
            "op": "replace",
            "value": {
                "id": "3322",
                "displayName": "Test"
            }
        }
    ]
}

根据SCIM规范（RFC7643第3.1节）：

It MUST be a stable, non-reassignable identifier that does not change when the same resource is returned in subsequent requests. The value of the "id" attribute is always issued by the service provider and MUST NOT be specified by the client.

（中文翻译：id必须是稳定、不可重新分配的标识符，同一资源在后续请求中返回时其值不得改变。"id"属性的值始终由服务提供商分配，客户端不得指定。）

目前的疑问是：即便请求体中的id值与目标资源的id完全一致，当前返回400 Bad Request是否合理？是否应该直接忽略id属性继续处理？

规范解读与处理建议 #

1. 严格合规性判断
   按照RFC7643的明确规定，客户端在请求中指定id属性的行为违反了SCIM规范，服务提供商返回400 Bad Request完全符合规范要求。

2. 生态兼容性考量
   实际场景中，包括Okta、Jumpcloud在内的主流身份提供商存在发送此类请求的情况。为保证服务兼容性，多数成熟的SCIM服务实现会选择忽略请求体中的id属性，仅处理其他合法属性的更新操作。

3. 补充规范依据
   SCIM API规范（RFC7644第3.5.2节）提到，服务提供商对于请求中不符合规范的属性，可选择忽略或返回错误。规范优先要求客户端不发送此类属性，但并未强制要求服务提供商必须报错，这给兼容性处理留出了空间。

结论 #

• 若追求严格遵循SCIM规范，返回400 Bad Request是合理的；
• 若需要兼容主流身份提供商的实际行为，忽略id属性并继续处理其他属性的更新是更务实的选择。

内容的提问来源于stack exchange，提问作者Philip Zwei