如何選擇身份供應商：工程團隊的評估框架

大多數身份供應商比較文章都是身份供應商自己寫的。令人驚訝，對吧？他們列出自己產品的功能，跳過沒有的，然後稱其為「客觀指南」。

這不是那種文章。

我們審閱了數十份企業的實際評估需求——採購團隊發給供應商的真實電子表格和 RFP 文件。規律很明顯：工程團隊往往低估最重要的標準，而高估最不重要的。

結果是什麼？團隊根據 demo 選擇了 IdP，六個月後發現遷移變成噩夢，又要重新評估。

這是我們希望在開始前有人給我們的評估框架。它是為 B2B SaaS 公司裡的工程團隊設計的——是那些建產品的人，不是買內部員工 SSO 的人。

快速答案：決定 IdP 最重要的因素#

如果你只想速讀，這裡有重點：

1. 協定深度比功能數更重要。 支援「OAuth2」不代表什麼。有哪些授權模式？能否自訂 token claims？你能不能讓自己變成 OIDC provider？
2. 遷移能力是最被低估的關鍵。 如果你無法在不強制重設密碼的情況下把現有用戶遷移過來，這個 IdP 基本不能用——其他再好也沒用。
3. 多租戶必須原生支援，不能只是補丁方案。 如果組織架構和每租戶設定都要靠 workaround，你會永遠在和系統搏鬥。
4. AI 準備不是未來需求——而是 12 個月內就會遇到的要求。 Token 交換、agent 身份、委託 scope。如果 IdP 不支援這些，你明年還得回來再比較一次。

以下的指南會針對每個評估面向逐項講解，告訴你具體該問什麼、哪些情況要小心。

適合對象（以及不適合誰）#

如果以下描述符合你，這份指南適合你：

• 你是 50-300 人 B2B SaaS 公司的 CTO、工程副總，或平台架構師
• 你有 100K+ 現有用戶，無法承受破壞性的遷移
• 你計劃進軍企業級客戶，需要 SSO、組織架構和審計日誌
• 你需要寫技術評估報告，想要一份不是供應商出的評估框架

不適合你的情況：

• 你需要 workforce IAM（員工內部 SSO）——那是另一種選購決策
• 你的新創只有 500 個用戶，還沒進入企業市場——選 SDK 最好用的就行
• 你想找的是身分驗證（KYC/KYB）——這完全是不同類型產品

面向一：協定能力——不是只有「支援 OAuth2」#

市面上的 IdP 都會告訴你它支援 OAuth2 和 OIDC。這只是基本。真正要問的是有多深入。

授權模式：有哪些與為什麼重要#

必備：

• Authorization Code + PKCE —— 唯一應用於瀏覽器和手機 app 的流程。如果供應商還推薦隱式流程，直接跳過。PKCE 不是選項，是安全必須。
• Client Credentials —— 給 service-to-service 溝通用。你的後端服務之間，需要無需用戶就能認證的能力。
• Refresh Token —— 這聽起來很基本，但細節差很多。能否自訂 rotation？過期時間？可以只撤銷單一 refresh token 而不影響整個 session 嗎？

越來越重要的功能：

• Token Exchange (RFC 8693) —— 支援 AI agent 認證、冒充流程和委託。今天沒有，要問清楚未來規劃，沒規劃就是大紅燈。

OIDC Provider 能力#

多數團隊沒問過：這個 IdP 可以當 OIDC 供應者用嗎（而不只是 OIDC 客戶端）？

為什麼重要：你的 SaaS 發展後，夥伴和客戶會想用你的身份系統登入他們自己的工具。你要發 tokens、處理同意、管理第三方 app 註冊。如果 IdP 只能消費外部 IdP，但不能自己作為 IdP 提供者，遇上 federation 需求就卡關。

你要問：

• IdP 有沒有可 white-label 的 OpenID Discovery endpoint？
• 能不能區分註冊不同信任層級的一方/三方應用？
• 第一方應用可以略過同意畫面，第三方應用要強制同意嗎？

JWT 自訂化#

Token 是你 IdP 跟服務之間的契約。如果不能自訂，所有下游服務都要多打一個 API 才能判斷用戶有什麼權限。

提問：

• 能不能在 access token、ID token 裡加入自訂 claims？
• 可以直接把組織（tenant）的 context 放進 token 裡嗎？
• 可以自訂 scope，讓 scope 跟自己的權限模型對應嗎？
• Claims 是在 token 發放時算的？還是能用 webhook、腳本動態生成？

一個帶 { "org_id": "org_123", "role": "admin", "auth_level": 2 } 的 token，你 API middleware 一行就能判斷權限。只有 { "sub": "user_456" } 的 token，所有服務都要補叫 IdP 或查資料庫。規模大時，這差的就是一個請求 2ms 跟 200ms 的差距。

面向二：認證流程——那些細節才會踩雷#

每家 IdP 都有 email/password 跟社交登入，你只是通過了最基本篩選。

真正的差異，在於 demo 裡沒提到的細節。

註冊流程#

• 註冊後自動登入：用戶註冊完，會自動登入？還是又跳回登入頁？強制重登超殺轉換率。你會驚訝有多少 IdP 這也能搞錯。
• 自訂註冊欄位：能在註冊時收集角色、公司名、用途嗎？還是要另外補 onboarding？
• 漸進式蒐集個資（progressive profiling）：能分階段、分次數補齊用戶資料，而不是一次收齊嗎？

登入流程#

• login_hint 支援：用戶從 EDM 點登入連結，能不能預填 email？這看似小事，其實是 EDM 登入成功率 40% 跟 60% 的差別。
• 組織特定的認證政策：A 公司可以強制 SAML SSO，B 公司只要 email/password？企業 tenant 強制 MFA？如果 per-tenant auth policy 只能靠寫 code，就等著每 onboard 一個企業客戶都要燒工程資源。
• 畫面自訂能力：登入 UI 能 per-tenant 自訂嗎？不只是 logo、色系，要能全 CSS 控制、custom domain、white-label email。能不能自己選「用代管 UI 或自訂 UI」。

多數清單忽略的重點#

• 靜默認證（silent authentication）：token 過期時，App 能不能靜默 refresh 而不用把用戶導回登入？refresh token 也過期時，有沒有 fallback（iframe sliding session）？
• 帳號關聯（account linking）：用戶第一次用 Google 註冊，第二次用 email，要變成兩個帳號還是一個？IdP 怎麼做 identity merging？做錯就會有無限鬼魂帳號。
• 無密碼選項：magic link、passkeys、WebAuthn。不是現在就要，但六個月內你一定會遇到企業客戶這樣問。

面向三：Session 與 Token 管理——水很深#

這部分設計 demo 看不出端倪。Session 跟 token 管理超無聊但是出事時會一次登出所有用戶。

Cookie 安全#

一點都不酷，但絕對重要。

• HttpOnly、Secure、SameSite 屬性：三個都要正確設置，session cookie 沒設 HttpOnly 根本不能上 production。
• 跨子網域支援：如果 app 在 app.yourproduct.com，API 在 api.yourproduct.com，session 能跨網域嗎？怎麼做？
• 第三方 cookie 淘汰：Chrome 要全面禁用第三方 cookie。IdP 怎麼解決跨站點認證？答案是「我們還在研究」就不行。

切換帳號與長存 sessions#

用戶希望幾個禮拜都不用重登入。但 180 天持久 session 跟 30 分鐘 session 安全風險完全不同比例。

要問：

• 能不能獨立設定 session 時長跟 token 有效期？
• 有沒有「記住我（remember me）」選項能延長 session 但 token 依然短效？
• 能不能只針對敏感操作強制再認證，而不影響全域 session？

Refresh token 安全#

• Token 輪換（rotation）：refresh token 每用一次會自動換嗎？（應該要會）
• 加密存取：refresh token 在硬碟上有無加密？
• 撤銷粒度：可以只撤銷某台設備的 session，而不殺掉所有 session？
• 過期可自訂：不同 app 需要不同的 refresh token 有效期，能 per-app 調整嗎？還是全域 only？

面向四：授權模型——超越基本 RBAC#

角色基礎權限控管 (RBAC) 是最底線，沒有的話這 IdP 就沒必要考慮。對 B2B SaaS 來說，單純 RBAC 還不夠。

組織範圍的權限#

你的用戶有組織，他們在每個組織內的權限跟全平台的權限是分開的。

同一個用戶在 A 組織是 admin，B 組織只是 viewer。IdP 如果不能原生建模，你自己做一整套就是雙來源（double source of truth）。

提問：

• 能不能在 org 層級定義角色，不止 user 層？
• 同一個 user 可以在不同 org 有不同角色？
• Token 裡會有目前操作 org 的 context 嗎，API 怎麼知道他在哪個 org？

多層級認證（auth_level）#

金融、醫療或任何高風險操作，權限需求不只是過個 session cookie 就好。

例如，瀏覽 dashboard 只需 session cookie，發動匯款要 MFA 再驗證一次。

這就是 step-up auth，要有 認證等級（auth_level） 的概念在 token 裡面。

要問：

• Token 能不能帶 auth_level claim 供後端查？
• 可以不用整個重登入，只針對單一操作觸發 step-up 認證？
• auth_level 的有效期可否獨立管理？

IdP 不原生支援，你只能自己重做一套——這正是你買 IdP 為了避免的事。

Token 做授權決策#

最理想的方式：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 支援：

• 能呼叫舊系統的 custom authentication hook
• 能在登入時即時建立帳戶（on-the-fly registration）
• 能追蹤哪些人已經搬走哪些還沒

三、雙寫（dual-write，並行運作）

轉換過程，舊系統跟新系統一起動，新寫入兩邊同步，讀逐漸切到新系統。有 roll-back，但管理很複雜。

遷移的警訊#

• 「支援 CSV 匯入」——只能搬資料檔案，無法搬密碼。還是得密碼重設。
• 「我們有遷移教學」——一定要看仔細。如果寫「用戶要設定新密碼」，就是會流失 30-50%。
• 完全沒談 hash 兼容——供應商根本沒處理過你這級規模。

你要問：#

• 支援哪種密碼 hash 匯入？（bcrypt、argon2、scrypt、PBKDF2、還是自訂？）
• 能不能邊登入邊遷移？
• 能追蹤用戶遷移進度比例嗎？
• 遷移失敗有 rollback 嗎？
• 能不能整個過程中 session 不中斷？

供應商回答不自信就可以跳過。

面向六：多租戶——原生還是補丁？#

B2B SaaS 必有多租戶。你的客戶是組織，有多名用戶、多種角色、存取政策。IdP 必須「懂」這一點。

什麼叫「原生多租戶」#

• 組織是主體：不是加個自訂欄位在用戶裡，而是有獨立 ID、設定、成員清單的正式資料模型。
• 組織有獨立的認證政策：A org 用自家 SAML SSO。B org 用 email/password+MFA。C org 用 Google Workspace。這些都能 UI 或 API 設定，不用寫 code。
• 組織邀請跟成員管理：每 org 的管理員能邀請、賦予角色、移除成員。IdP 本身負責邀請信、驗證、分配角色。
• 組織範疇 tokens：用戶在某 org 操作時，token 帶 org 組織資訊，API 能查清楚該給哪個 org 的資料。

「自訂 metadata」workaround#

有些 IdP 沒有原生 org model，只叫你把 user.app_metadata.org_id = "123" 當 workaround。

很快就炸鍋：

• 用戶屬於多 org 要用陣列自己玩
• 沒內建 invitation 跟 membership 流程
• 沒 per-org 認證政策
• Token 沒 org context——要你自己猜
• Audit log 完全不認得組織

供應商說「你可以用 metadata 做 org」，那就是把關聯資料存在 JSON 欄位了，能跑但總有天出問題。

你要問：#

• 是原生組織模型還是硬疊在 metadata 上？
• 用戶能多 org 並存嗎？
• 能 per-org 設定認證規則嗎？
• 支援組織範疇的角色和權限嗎？
• 組織管理員能自助管理成員嗎？
• Token 有帶 org context 嗎？

面向七：AI 準備度——你現在可能還沒想到#

一年前沒人在評分表裡問「AI agent 認證」。現在只要你要做 AI 功能——copilot、autonomous agent、AI workflow——IdP 必須支援一種新型態身份：agent。

為什麼 agent 打破傳統模式#

傳統認證只有兩種：用戶、應用程式。OAuth2 就是這樣設計的。

AI agents 帶來第三種：非人類 entity，代替用戶行動，有自己的權限界線、審計紀錄。

• agent 不是 user——沒有密碼或瀏覽器 session
• agent 不是單純 M2M——而是「代表某個用戶操作」
• agent 需要 scope 化、限期授權——不能用全部 user 的完整權限

IdP 必須支援什麼#

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（Model Context Protocol）兼容性#

MCP 正成為 AI agent 與服務互動的標準。如果 IdP 能用 OAuth 認證 MCP servers，agent 就不必用 API key 或共享密碼，直接走標準協定。

你要問：#

• 支援 OAuth2 Token Exchange 嗎？
• agents 能作為獨立 client type？
• tokens 能記載 delegation（誰授權、何 scope）資訊？
• 審計 log 能分辨 agent 跟人類行為嗎？
• MCP 伺服器能整合？agent 工具間有 OAuth 認證嗎？

供應商沒想過這些，只適合 2020，不適合 2026。

面向八：非功能性需求——最讓你徹夜難眠的那些 n#

功能賣得動。「日常運營」才是真正決定會不會續約的關鍵。

效能#

• 認證流量吞吐量：高峰可否每秒 100+、甚至 1000+ 認證請求？
• Token 驗證延遲：jwt 本地驗證應該是 sub-ms。如果懶得 introspection，P99 latency 多長？
• 可擴展上限：單月活用戶到底能支援多少？有無 ran 到你需求等級的實證？

合規#

• SOC2 Type II：不是 Type I。Type II 是「被審查一段期間」不是只審查某天。如果只有 Type I，問一下啥時轉 Type II。
• 審計日誌：所有認證、權限更改、管理操作都要 log。能不能導出到 SIEM？log 是否不可修改？
• 資料所在區（data residency）：能指定存放區域？歐盟客戶強制要這規格。

穩定性#

• 運作保證（SLA）：99.9% 一年 8.7 小時停機，99.99% 只 52 分鐘。認證就是大門，差這 8 小時，可意會不可言傳。
• 容錯：供應商掛點時會怎麼辦？有無備援？多區域？
• 事故紀錄：查狀態頁，不只聽 promises，看歷史。

資料可攜#

• 用戶可導出：能導出全部用戶資料及 metadata、org 與角色？格式是？
• 標準協定兼容：用 OIDC、SCIM 這種標準，日後換平台搬家才可行。
• 無綁定：自家 API、自定義協定、非標準 token 全是 lock-in 沒跑。越 proprietary，越難換跑道。

評估矩陣：實用打分框架#

評完各面向後，要能比較。這有個優先級打分表：

P1——底線，不通過即出局#

P2——強烈偏好（沒這些很傷工程）#

P3——重要（12 個月內必定遇到）#

P4——加分但非關鍵#

**用法：**從 P1 開始，有任何一條沒過直接淘汰。再看 P2、P3 分數。P2+P3 最高分就是答案。

常見評估錯誤#

我們見過同樣錯誤被重複很多次，如何避免：

錯誤一：只看功能不看底層實作#

只比功能清單，只看到表面。有些 IdP 「支援組織」只是 user metadata 寫 org_id，excel 格子打勾，到 production 會爆。

解法：每個功能都問「你怎麼做的？」不只是「有沒有做？」

錯誤二：忘記遷移問題#

選好 IdP 才發現原用戶必須重設密碼，流程爆炸，只能黯然重啟評估。

解法：先用遷移能力篩選。

錯誤三：看 demo 被騙#

每家供應商 demo 都很漂亮。乾淨資料庫、零邊緣案例。你的 production 有合併帳戶、unicode 問題、卡死 session。

解法：要用真資料 proof-of-concept，倒 1000 筆用戶進去，跑你的流程。

錯誤四：沒讓正確的人參與#

只工程團隊參加只會顧結構，只有產品只選整合快的，只信息安全只考 compliance 清單。

解法：團隊要工程、產品跟安全都要參與，每人負責不同 P1/P2 標準。

錯誤五：忘了有天會換家#

Vendor lock-in 很現實。專有 SDK、私人 API、非標準 token 格式，只會讓以後更難換。

解法：選支援標準協定（OIDC、OAuth2、SCIM）的 IdP。未來自己會感謝現自己。

常見問題 FAQ#

IdP 評估要多久？#

全流程含 PoC 測試，保守估 4-8 週。急就章就會踩前面那些坑（特別是遷移）。規劃上：2 週收需求，2-3 週供應商比較 & PoC，1-2 週內部統整。

要不要自建 auth？#

跟階段有關。用戶不到萬、不做企業需求，輕量 lib 就可以。但要用 SSO、多租戶、MFA、合規，自己維護 auth 成本絕對高於 IdP 授權費。我們看過團隊一年燒 2-3 個全職工程師維 auth，這透明機會成本 30-50 萬美金。

CIAM 跟 workforce IAM 有什麼不同？#

CIAM 是產品終端用戶登入、註冊、profile 管理那一套；workforce IAM 是內部員工用的（像 Okta 登 Slack、Google Workspace 等等）。是不同選購邏輯。這篇只講 CIAM。

開源 IdP 比私有好在哪？#

開源好處是透明（能審查 code）、可攜（要自架也行）、有社群支援。商業 IdP UI 更好、服務免維護。重點不是 open vs closed，而是「我以後能不能走？」開源方案通常遷出更容易，因為數據模型跟 API 都公開。

AI agent 認證何時要優先 (P1) 考慮？#

只要已經在做 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 當成基礎設施不是一次性功能。