繁體中文（台灣）
如何選擇身分識別服務提供者：工程團隊的評估框架
一個從真實企業需求出發、實用的 IdP 評估框架。涵蓋協定深度、遷移、多租戶、AI 準備度，以及多數檢查表忽略的關鍵標準。
Yijun
Developer
Developer
一個從真實企業需求出發、實用的 IdP 評估框架。涵蓋協定深度、遷移、多租戶、AI 準備度，以及多數檢查表忽略的關鍵標準。
大多數身分識別服務提供者（IdP）的比較文章，都是由 IdP 自己撰寫的。很驚訝吧？他們列舉自家產品有的功能，跳過沒有的，然後稱這是「客觀指南」。
這篇不是那種文章。
我們檢閱了數十份企業真實的評估需求 —— 包含採購團隊遞交給廠商的實際試算表與 RFP 文件。模式很明顯：工程團隊往往低估最重要的標準，卻高估那些最無關緊要的。
結果？團隊根據 demo 選了 IdP，六個月後才發現遷移是一場噩夢，不得不重新開始評估。
這是我們希望有人在出發前給我們的評估框架。它是專為 B2B SaaS 公司的工程團隊打造 —— 真的在開發產品，而非只是幫員工採購內部 SSO。
如果你只想快速瀏覽，重點在這裡：
本指南以下會逐一詳細說明評估維度、具體問題與紅旗預警。
適用於你如果：
不適用於你如果：
每個市面上的 IdP 都說支援 OAuth2 和 OIDC。這只是基本門檻。真正該問的是細節深度。
不可或缺：
越來越重要：
大多數團隊沒想到要問這個問題：這個 IdP 能作為 OIDC Provider（不只是 consumer）嗎？
為何重要：隨著 SaaS 擴大，合作夥伴和客戶可能希望用你的身份系統登入他們的工具。你需要簽發 token、管理同意、第三方 app 註冊。如果 IdP 只能消費外部 IdP，無法作為 provider，未來要做外部 federation 就會卡住。
請問：
token 是你的 IdP 和服務之間的契約。如果不能自訂，每個下游服務就必須再查一次 API 才知道用戶能做什麼。
請問：
token 如果攜帶 { "org_id": "org_123", "role": "admin", "auth_level": 2 }，API middleware 可以一行決定授權。如果只有 { "sub": "user_456" }，就要回 IdP 或資料庫查。規模大時，這差的是每次請求 2ms 與 200ms 的差別。
每個 IdP 都有 email/password 和社群登入。恭喜你，所有廠商都進入名單。
差異藏在 demo 不會帶到的流程細節。
這裡是真正分出專業與外行的分界。Session 與 token 管理平常很無聊，爆炸時全體用戶都會被登出。
不性感，但絕對關鍵。
app.yourproduct.com 跟 api.yourproduct.com，Session 能橫跨子網域嗎？怎做到的？用戶要能登入狀態保持數週，不是數分鐘。但 180 天持久會話與 30 分鐘 session 風險完全不同。
請問：
RBAC 是底線。沒支援 RBAC 直接淘汰。但對 B2B SaaS，僅靠 RBAC 遠遠不夠。
用戶屬於不同組織。在每組織內的權限和在平台上的權限不同。
同一個用戶可在 A 組織為 admin，在 B 為 viewer。如果 IdP 無法原生建模，你會重做一套權限系統 —— 多了個真實資訊源。
請問：
金融、醫療、須分權限風險的產品：不是所有已認證的 Session 都有同樣風險。
看報表？Session cookie 夠。匯款？需要 MFA 即時加強認證。
這叫「步進式認證」，需要 auth_level 這個概念在 token 裡。
請問：
auth_level 欄位給後端查詢？auth_level 是否有自己獨立過期時間？IdP 無原生支援，你就得自己重造輪子 —— 當初買 IdP 本來就是要避免自己造！
理想：API middleware 讀 token，直接看 org、role、auth_level 做授權決策，不依靠外部服務。
現實：多數 IdP token 只告訴你 user 是誰，允許做什麼還得查一個 API。
多一次查詢就多一個延遲，多一個依賴，多一個失效點。每秒一千請求還要過網路查授權，你不會想這樣。
沒人愛談這點：多數 IdP 導入最後不是功能不夠好，而是團隊搞不定用戶帳號遷移。
有十萬以上用戶時，遷移不是「加分」，而是「整個專案」的關鍵。
1. 直接匯入密碼 hash
現有用戶密碼都經 bcrypt/argon2 等計算。IdP 能否直接匯入 hash 直接驗證？
能：用戶用舊密碼繼續登入，一切無感。最佳。
不能：全部用戶收到重設密碼 email，遷移會淘汰 30-50% 帳號。不是假設，我們見過真實案例。
2. 漸進式（lazy）遷移
不一次遷移所有用戶，誰登入才搬。首次登入查舊系統，驗證密碼後新 IdP 加帳號。後續就用新 IdP。
大用戶基數最安全，需要：
3. 雙寫（平行運行）
轉換期同時維護舊新 Id 系統。寫同步到兩邊，讀逐步切回新系統。可回滾，但營運複雜度暴增。
廠商答不出以上，代表沒做過大型遷移，請直接淘汰。
B2B SaaS 必然有多租戶：你的客戶是組織，有多用戶、多角色、多權限。IdP 必須原生支持這種結構。
一些 IdP 無原生組織模型，叫你用自訂 user metadata（例如 user.app_metadata.org_id = "123"）。
會很快惡化：
如果有人說「可用 metadata 自訂模擬組織」，那就是用 JSON 欄位存關聯式資料，撐一陣子就爛了。
一年前 AI agent 認證還不在任何檢查表裡。今天要做 AI 功能 —— copilot、agent、AI 工作流程 —— IdP 就得處理新型態「代理」身分。
傳統認證是「用戶」和「應用」兩個角色。OAuth2 設計也是這種。
AI agent 是第三種：
Token Exchange (RFC 8693)： 代理提供自己 credential ＋ 用戶授權，取得含範圍的 token。token 得記載：誰（用戶）、哪個代理、scope（權限）、到期時點。
代理為一種 client 類型： 代理須是正規 OAuth2 client（有獨立 client_id），不能是 API key 或共享 user token 越權。
委派 scope 管理： 用戶授權代理只准讀、或只允許存取某類資源。
稽核區分：稽核日誌要區分「user 做」和「代理幫 user 做」。不區分就過不了 SOC2：審計會問每筆異動是誰發生的。
MCP 正成為 AI agent 與工具服務互動的標準。IdP 若支援 OAuth 為 MCP server 認證，代理就能走協定安全認證（不是 API key）。
廠商沒想過，代表只在做 2020 年的產品。你該規劃 2026 年用的。
功能賣得動，營運才決定是否續約。
跨各維度評估後，需要量化比較。這裡有個優先等級：
| 標準 | 為什麼 P1 |
|---|---|
| 密碼 hash 匯入或漸進式遷移 | 不能遷移就不能用 |
| Authorization Code + PKCE | 基本安全底線 |
| 原生組織模型 | B2B SaaS 必備 |
| SOC2 Type II 或明確實現路徑 | 企業客戶會問 |
| 99.9%+ uptime SLA | 認證掛了等於產品掛了 |
| 標準 | 為什麼 P2 |
|---|---|
| 可自訂 JWT claim | 不用每次查權限 API |
| 組織級認證政策 | 企業 onboarding |
| 組織級角色與 token | 多租戶授權 |
| Refresh token 旋轉與撤銷 | 安全標準 |
| Hosted UI + 自訂 UI 選擇 | 彈性適用不同情境 |
| 標準 | 為什麼 P3 |
|---|---|
| Token Exchange (RFC 8693) | AI agent 認證 |
| OIDC Provider 能力 | 合作夥伴 federation |
| 步進式認證 / auth_level | 金融／高風險行為 |
| SCIM Provisioning | 企業客戶目錄同步 |
| Passkey / WebAuthn 支援 | 推向無密碼未來 |
| 標準 | 為什麼 P4 |
|---|---|
| 內建分析儀表板 | 查稽核日誌也能補做 |
| 自訂品牌 email 樣板 | 便利性 |
| 視覺化流程設計器 | 便利性 |
| 社群登入連接器（前五大以外） | 長尾需求 |
用法：從 P1 開始。廠商有一項 P1 不過就淘汰。再評 P2、P3 類別。P2+P3 得分高的就是答案。
我們反覆見到團隊犯相同錯誤，避免方式如下：
功能比較表只能說有無，但無法告訴你怎麼做。IdP 可能靠 user metadata 存 org_id，excel 打勾沒錯，上線就災難。
解法：每項功能都問「實作方式？」不是「有沒有這個？」
團隊選定「最佳」 IdP，進開發才發現用戶不能無感遷移，只有推密碼重設一途。最後只好硬頭皮遷移或重頭再評。
解法：遷移應放第一關，不是最後一關。
廠商的 demo 都很完美。乾淨資料、無邊界案例。你的實際環境會有合併帳號、奇怪 unicode、怪 session。
解法：要 proof-of-concept 用你真實資料。匯入 1,000 個真實 user，做真實驗證流程。
只讓平台工程師評比，他們會挑技術最清潔的。只讓產品團隊，會選整合最快的。只讓資安，會選 compliance 最多的。
解法：評估團隊要有平台工程、產品、資安。各自負責不同 P1/P2 標準。
廠商綁死是真的，專屬 SDK、自訂 API、特殊 token，日後超難搬家。
解法：偏好用標準協定（OIDC、OAuth2、SCIM）的 IdP。你未來會感謝自己。
如要完整包含 POC 測試，預估需 4-8 週。心急只會犯上面提的遷移漏評等錯誤。建議 2 週需求調查、2-3 週廠商評估＋ POC、1-2 週內部協調。
看階段。用戶低於萬數、沒企業客戶，可以輕量 auth library。若需 SSO、多租戶、MFA、合規文件，自建成本立刻超越 IdP。見過工程團隊為此全年兩三個人在維護等同 300-500 萬台幣。
CIAM（Customer Identity & Access Management）是產品終端用戶會碰的（註冊、登入、管理），workforce IAM 是員工用來上內部工具（Okta for Slack/Google Workspace 等）。兩者採購與評選邏輯完全不同。本指南僅談 CIAM。
開源 IdP 有透明度（可 audit 原始碼）、可移植（可自架），有社群。專有家 UI 與維運通常優。關鍵不是「開 vs. 閉」，而是「想走時帶得走嗎？」開源資料模型、API 都公開，遷移較易。
已經有 AI 功能會代理用戶存取資料時（copilot、workflow、AI 助理），現在就該列 P1。若 6-12 個月規劃內，就保留在 P3 但加重權重。不在規劃，暫放 P4，半年後重看。
多數 IdP 按 MAU（每月活躍用戶）計價。但「MAU」定義大不同——有人算登入次數、有人算獨立用戶，有些 M2M token 另收。請廠商針對你需求（X user, Y org, Z M2M, 估算流量）給實際報價。要比總價，不是單位價。
選 IdP 是基礎架構決策，不是純粹功能比一比。它關乎每位用戶最初接觸產品、每筆 API 權限檢查、每筆合規稽核日誌。
以上評估框架關注的是什麼真的影響結果，而非行銷文案。用它快速篩選（P1 先過）、深入評估（P2+P3 搭配 POC），選出能撐數年而非數月的解方。
做對的團隊有個共通點：把身分管理當基礎設施，不是寫完就忘的附屬功能。