一個根據真實企業需求建立的實用 IdP 評估框架。涵蓋協定深度、遷移、多租戶、AI 準備度，以及大多數清單忽略的標準。
大多數身份供應商比較文章都是身份供應商自己寫的。令人驚訝，對吧？他們列出自己產品的功能，跳過沒有的，然後稱其為「客觀指南」。
這不是那種文章。
我們審閱了數十份企業的實際評估需求——採購團隊發給供應商的真實電子表格和 RFP 文件。規律很明顯：工程團隊往往低估最重要的標準，而高估最不重要的。
結果是什麼？團隊根據 demo 選擇了 IdP，六個月後發現遷移變成噩夢，又要重新評估。
這是我們希望在開始前有人給我們的評估框架。它是為 B2B SaaS 公司裡的工程團隊設計的——是那些建產品的人，不是買內部員工 SSO 的人。
如果你只想速讀，這裡有重點：
以下的指南會針對每個評估面向逐項講解，告訴你具體該問什麼、哪些情況要小心。
如果以下描述符合你，這份指南適合你：
不適合你的情況：
市面上的 IdP 都會告訴你它支援 OAuth2 和 OIDC。這只是基本。真正要問的是有多深入。
必備：
越來越重要的功能：
多數團隊沒問過：這個 IdP 可以當 OIDC 供應者用嗎（而不只是 OIDC 客戶端）？
為什麼重要：你的 SaaS 發展後，夥伴和客戶會想用你的身份系統登入他們自己的工具。你要發 tokens、處理同意、管理第三方 app 註冊。如果 IdP 只能消費外部 IdP，但不能自己作為 IdP 提供者，遇上 federation 需求就卡關。
你要問：
Token 是你 IdP 跟服務之間的契約。如果不能自訂，所有下游服務都要多打一個 API 才能判斷用戶有什麼權限。
提問：
一個帶 { "org_id": "org_123", "role": "admin", "auth_level": 2 } 的 token，你 API middleware 一行就能判斷權限。只有 { "sub": "user_456" } 的 token，所有服務都要補叫 IdP 或查資料庫。規模大時，這差的就是一個請求 2ms 跟 200ms 的差距。
每家 IdP 都有 email/password 跟社交登入，你只是通過了最基本篩選。
真正的差異，在於 demo 裡沒提到的細節。
這部分設計 demo 看不出端倪。Session 跟 token 管理超無聊但是出事時會一次登出所有用戶。
一點都不酷，但絕對重要。
app.yourproduct.com，API 在 api.yourproduct.com，session 能跨網域嗎？怎麼做？用戶希望幾個禮拜都不用重登入。但 180 天持久 session 跟 30 分鐘 session 安全風險完全不同比例。
要問：
角色基礎權限控管 (RBAC) 是最底線，沒有的話這 IdP 就沒必要考慮。對 B2B SaaS 來說，單純 RBAC 還不夠。
你的用戶有組織，他們在每個組織內的權限跟全平台的權限是分開的。
同一個用戶在 A 組織是 admin，B 組織只是 viewer。IdP 如果不能原生建模，你自己做一整套就是雙來源（double source of truth）。
提問：
金融、醫療或任何高風險操作，權限需求不只是過個 session cookie 就好。
例如，瀏覽 dashboard 只需 session cookie，發動匯款要 MFA 再驗證一次。
這就是 step-up auth，要有 認證等級（auth_level） 的概念在 token 裡面。
要問：
auth_level claim 供後端查？auth_level 的有效期可否獨立管理？IdP 不原生支援，你只能自己重做一套——這正是你買 IdP 為了避免的事。
最理想的方式：API middleware 光看 token，驗證 org、role、auth_level 就給權限，不用外部 service。
多數 IdP 的現實是：token 只告訴你用戶是誰，還必須額外 call API 才知道他能做什麼。
這種 call 讓你有延遲、有依賴、還產生故障點。每秒一千請求，你不會想檢查權限都去跳 API。
有個沒人願意講的現實：IdP 評估最後最常失敗不是新 IdP 不夠好，而是團隊搞不定舊用戶怎麼遷。
有 10 萬以上用戶，遷移不是 nice-to-have，而是專案本身。
一、大量匯入現有密碼 hash
你現有的密碼是 bcrypt、argon2 或其他 hash。IdP 能否直接吃 hash，並用這 hash 來驗證密碼？
可以的話：原用戶照常登入，完全無縫。最佳解。
不可以：全部用戶要「重設密碼」。遷移會直接流失 30-50% 用戶。這不是嚇你的——真的發生過。
二、漸進式（lazy）遷移
不是一次全部搬走，而是用戶首次登入時才舊系統驗證密碼，然後創建 IdP 帳號。之後直接用新 IdP。
最適合大用戶群，但要 IdP 支援：
三、雙寫（dual-write，並行運作）
轉換過程，舊系統跟新系統一起動，新寫入兩邊同步，讀逐漸切到新系統。有 roll-back，但管理很複雜。
供應商回答不自信就可以跳過。
B2B SaaS 必有多租戶。你的客戶是組織，有多名用戶、多種角色、存取政策。IdP 必須「懂」這一點。
有些 IdP 沒有原生 org model，只叫你把 user.app_metadata.org_id = "123" 當 workaround。
很快就炸鍋：
供應商說「你可以用 metadata 做 org」，那就是把關聯資料存在 JSON 欄位了，能跑但總有天出問題。
一年前沒人在評分表裡問「AI agent 認證」。現在只要你要做 AI 功能——copilot、autonomous agent、AI workflow——IdP 必須支援一種新型態身份：agent。
傳統認證只有兩種：用戶、應用程式。OAuth2 就是這樣設計的。
AI agents 帶來第三種：非人類 entity，代替用戶行動，有自己的權限界線、審計紀錄。
Token Exchange (RFC 8693)： agent 拿自己憑證加上用戶授權，換取得 scope 化 token。token 會帶上：誰（user）、誰（agent）、scope（權限範圍）、何時失效（過期）。
Agent 是一種 client type： agent 要有自己的 client_id，是 OAuth2 client 不是 API key hack。
授權可委託 scope 管理： 用戶能授權 agent 個別權限——只讀不能寫，某些資源開、某些關。
審計區分： 日誌必須能分辨「user 做的」還是「agent 替 user 做的」。分不出來，下次 SOC2 audit 都過不了，審查員一定會問「誰改的？」
MCP 正成為 AI agent 與服務互動的標準。如果 IdP 能用 OAuth 認證 MCP servers，agent 就不必用 API key 或共享密碼，直接走標準協定。
供應商沒想過這些，只適合 2020，不適合 2026。
功能賣得動。「日常運營」才是真正決定會不會續約的關鍵。
評完各面向後，要能比較。這有個優先級打分表：
| 標準 | 為什麼屬於 P1 |
|---|---|
| 密碼 hash 可匯入或支援漸進遷移 | 不會遷不能用 |
| Authorization Code + PKCE | 基本安全門檻 |
| 原生組織模型 | 做 B2B SaaS 必備 |
| SOC2 Type II 或明確規劃 | 企業客戶都會問 |
| 99.9% 以上 SLA | 認證掛斷產品掛 |
| 標準 | 為什麼屬於 P2 |
|---|---|
| 自訂 JWT claims | 避免每次都查權限 |
| 每 org 認證政策 | 企业客戶快速上線 |
| org 角色與 token 都能分級 | 多租戶授權控管 |
| Token 輪換與撤銷 | 安全基本動作 |
| 可選代管 UI/自製 UI | 不同場景彈性 |
| 標準 | 為什麼屬於 P3 |
|---|---|
| Token Exchange (RFC 8693) | AI agent 認證 |
| OIDC Provider 能力 | 合作夥伴 federation |
| 上提認證/多層級 auth_level | 金融/高風險操作 |
| SCIM 目錄同步 | 企業客戶連動 |
| Passkey/WebAuthn | 無密碼方向 |
| 標準 | 為什麼屬於 P4 |
|---|---|
| 內建分析 dashboard | 審計 log 可取代 |
| White-label email 模板 | 小便利功能 |
| flow builder | 小便利功能 |
| 超過前五大社交鏈接 | 長尾平台用 |
**用法：**從 P1 開始，有任何一條沒過直接淘汰。再看 P2、P3 分數。P2+P3 最高分就是答案。
我們見過同樣錯誤被重複很多次，如何避免：
只比功能清單，只看到表面。有些 IdP 「支援組織」只是 user metadata 寫 org_id，excel 格子打勾，到 production 會爆。
解法：每個功能都問「你怎麼做的？」不只是「有沒有做？」
選好 IdP 才發現原用戶必須重設密碼，流程爆炸，只能黯然重啟評估。
解法：先用遷移能力篩選。
每家供應商 demo 都很漂亮。乾淨資料庫、零邊緣案例。你的 production 有合併帳戶、unicode 問題、卡死 session。
解法：要用真資料 proof-of-concept，倒 1000 筆用戶進去，跑你的流程。
只工程團隊參加只會顧結構，只有產品只選整合快的，只信息安全只考 compliance 清單。
解法：團隊要工程、產品跟安全都要參與，每人負責不同 P1/P2 標準。
Vendor lock-in 很現實。專有 SDK、私人 API、非標準 token 格式，只會讓以後更難換。
解法：選支援標準協定（OIDC、OAuth2、SCIM）的 IdP。未來自己會感謝現自己。
全流程含 PoC 測試，保守估 4-8 週。急就章就會踩前面那些坑（特別是遷移）。規劃上：2 週收需求，2-3 週供應商比較 & PoC，1-2 週內部統整。
跟階段有關。用戶不到萬、不做企業需求，輕量 lib 就可以。但要用 SSO、多租戶、MFA、合規，自己維護 auth 成本絕對高於 IdP 授權費。我們看過團隊一年燒 2-3 個全職工程師維 auth，這透明機會成本 30-50 萬美金。
CIAM 是產品終端用戶登入、註冊、profile 管理那一套；workforce IAM 是內部員工用的（像 Okta 登 Slack、Google Workspace 等等）。是不同選購邏輯。這篇只講 CIAM。
開源好處是透明（能審查 code）、可攜（要自架也行）、有社群支援。商業 IdP UI 更好、服務免維護。重點不是 open vs closed，而是「我以後能不能走？」開源方案通常遷出更容易，因為數據模型跟 API 都公開。
只要已經在做 AI 會觸及用戶資料（copilot、AI 助手等），現在就要列 P1。如果六到十二個月內必做 AI，要列 P3 但權重加重。AI 沒在規劃則暫歸 P4，但半年後要檢討一次。
大多數 IdP 按 MAU 定價。但 MAU 定義不同：有的算每次登入，有的算活躍用戶，有的 M2M tokens 分開計。要供應商報專屬你的 scenario（X 用戶、Y org、Z M2M，預期流量），比較總價，不要只看單價。
選擇身份供應商是基礎設施決策，不是純粹功能性選擇。這是一條要守護每位用戶首次體驗、API 權限審查、合規審計要求的關鍵路徑。
本評估框架涵蓋真正重要的點——不是行銷話術。用它快速篩掉候選（先查 P1 標準），細部比較看 P2 P3（PoC 跑流程），讓決策能撐得住未來幾年。
做對這件事的團隊都有一個共同點：把 identity 當成基礎設施不是一次性功能。