開場引言
在企業身分管理領域，帳號生命週期管理是核心需求。SPML 與 SCIM 都解決同一個問題：如何跨系統自動化建立、修改、停用帳號。兩者代表不同世代的技術哲學，理解差異有助於做出正確的整合決策。
SPML：XML/SOAP 時代的帳號管理協議
SPML（Service Provisioning Markup Language）由 OASIS 於 2003 年制定，建立在 XML 與 SOAP 之上。它定義了標準化的 Provisioning Service Provider（PSP）與 Provisioning Service Consumer（PSC）角色，透過 SOAP Envelope 傳遞帳號操作請求。
SPML 的最大痛點在於複雜度極高：每一個請求都需要包裝在冗長的 XML 結構中，開發者必須處理 WSDL、SOAP Fault、XML Schema 等繁瑣規格。實作成本高，互通性卻因廠商自定義擴充而降低。目前僅在 Oracle Identity Manager、IBM ISIM 等傳統地端 IAM 系統中仍可見到其蹤跡。
SCIM：JSON/REST 時代的雲端原生標準
SCIM 2.0（System for Cross-domain Identity Management）由 IETF 於 2015 年發布（RFC 7642–7644），以 RESTful API 與 JSON 為基礎。資源操作直接對應 HTTP 動詞：POST 建立、PUT/PATCH 修改、DELETE 停用，語義直觀且易於實作。
SCIM 定義了標準化的 User 與 Group Schema，並支援透過 /ServiceProviderConfig 端點自動發現能力。Okta、Azure AD、Google Workspace、Salesforce 均原生支援 SCIM 2.0，已成為 SaaS 整合的事實標準。
💡 重點整理：SPML vs SCIM 核心差異
- 傳輸格式：SPML 使用 XML/SOAP，SCIM 使用 JSON/REST，後者開發成本顯著更低。
- 標準化程度：SCIM 2.0 有 RFC 規範背書，Schema 統一，互通性遠勝 SPML。
- 適用場景：SPML 僅存於傳統地端 IAM，SCIM 主導現代 SaaS 與雲端身分整合。
- 遷移建議：新專案應直接採用 SCIM 2.0；舊系統若仍用 SPML，優先評估遷移路徑。
SCIM 請求範例
POST /scim/v2/Users
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "alice@example.com",
"active": true,
"name": { "givenName": "Alice", "familyName": "Chen" }
}結語
SPML 是歷史，SCIM 是現在與未來。選擇協議即選擇技術債的多寡。現代身分整合應以 SCIM 2.0 為唯一起點，避免重蹈 SOAP 時代的複雜性覆轍。