如何選擇身分識別服務提供者：工程團隊的評估框架

大多數身分識別服務提供者（IdP）的比較文章，都是由 IdP 自己撰寫的。很驚訝吧？他們列舉自家產品有的功能，跳過沒有的，然後稱這是「客觀指南」。

這篇不是那種文章。

我們檢閱了數十份企業真實的評估需求 —— 包含採購團隊遞交給廠商的實際試算表與 RFP 文件。模式很明顯：工程團隊往往低估最重要的標準，卻高估那些最無關緊要的。

結果？團隊根據 demo 選了 IdP，六個月後才發現遷移是一場噩夢，不得不重新開始評估。

這是我們希望有人在出發前給我們的評估框架。它是專為 B2B SaaS 公司的工程團隊打造 —— 真的在開發產品，而非只是幫員工採購內部 SSO。

快速解答：決定 IdP 成敗的關鍵#

如果你只想快速瀏覽，重點在這裡：

1. 協定深度比功能數量重要。 支援「OAuth2」本身沒意義。支援哪些授權類型？可以自訂 token 聲明嗎？你能自己成為 OIDC 提供者嗎？
2. 遷移能力是最被低估的標準。 如果不能在不強制重設密碼的情況下遷移現有用戶，這個 IdP 就是不可用的 —— 不管其他功能多棒都沒用。
3. 多租戶必須是原生支援，而非補丁。 如果組織模型和單一租戶設定需要 workaround，你永遠都在跟系統打仗。
4. AI 準備不是未來需求 —— 它是一年內的必要標準。 Token 交換、代理身分、委派範圍。如果 IdP 不支援這些，你明年還會再回來評估一次。

本指南以下會逐一詳細說明評估維度、具體問題與紅旗預警。

適用對象（以及不適用對象）#

適用於你如果：

• 你是 50-300 人 B2B SaaS 公司的 CTO、工程副總或平台架構師
• 你有超過十萬用戶，承受不起高干擾的遷移
• 你正準備進軍要求 SSO、組織模型、稽核日誌的企業客戶
• 你需要撰寫技術評估報告，且想用不是廠商提供的框架

不適用於你如果：

• 你需要的是 workforce IAM（員工用的 SSO 工具） —— 這是另一種採購決策
• 你是還沒企業客戶、僅 500 用戶的新創 —— 選 SDK 最好用的即可
• 你需要的是身份驗證（KYC/KYB）—— 那完全屬於另一類產品

維度一：協定能力 —— 不只是「支援 OAuth2」#

每個市面上的 IdP 都說支援 OAuth2 和 OIDC。這只是基本門檻。真正該問的是細節深度。

授權類型：支援哪些，為何重要#

不可或缺：

• Authorization Code + PKCE —— 瀏覽器及手機 app 唯一建議使用流程。如果廠商還推薦 Implicit flow，請直接淘汰。PKCE 並非選項，是安全標準。
• Client Credentials —— 服務對服務溝通。後台服務之間需無人認證。
• Refresh Token —— 乍看簡單，細節差異大。能設定 rotating 嗎？過期時間？可以只撤銷單一 refresh token，而非整個會話嗎？

越來越重要：

• Token Exchange (RFC 8693) —— 支援 AI agent 身分驗證、假冒（impersonation）和委派流程。如果現在沒，有沒有在 roadmap 上？沒有就是大紅旗。

OIDC Provider 能力#

大多數團隊沒想到要問這個問題：這個 IdP 能作為 OIDC Provider（不只是 consumer）嗎？

為何重要：隨著 SaaS 擴大，合作夥伴和客戶可能希望用你的身份系統登入他們的工具。你需要簽發 token、管理同意、第三方 app 註冊。如果 IdP 只能消費外部 IdP，無法作為 provider，未來要做外部 federation 就會卡住。

請問：

• IdP 是否有 OpenID Discovery endpoint 並可自訂品牌？
• 可區分第一方和第三方應用，並設置不同信任層級？
• 第一方 app 可跳過同意頁，第三方 app 必須同意頁嗎？

JWT 自訂#

token 是你的 IdP 和服務之間的契約。如果不能自訂，每個下游服務就必須再查一次 API 才知道用戶能做什麼。

請問：

• 能自定義 access token / ID token 的 custom claim 嗎？
• 可以把用戶目前作用的組織（租戶） context 加到 token 嗎？
• 可否自定 scope，和你的權限模型對應？
• claim 是簽發時計算，還是可以透過 webhook / script 動態嵌入？

token 如果攜帶 { "org_id": "org_123", "role": "admin", "auth_level": 2 }，API middleware 可以一行決定授權。如果只有 { "sub": "user_456" }，就要回 IdP 或資料庫查。規模大時，這差的是每次請求 2ms 與 200ms 的差別。

維度二：認證流程 —— 凶手藏在細節#

每個 IdP 都有 email/password 和社群登入。恭喜你，所有廠商都進入名單。

差異藏在 demo 不會帶到的流程細節。

註冊流程#

• 註冊後自動登入：用戶註冊後，有無自動登入？還是又要手動再登入？強迫剛註冊的用戶再登入，轉換率耗損嚴重。你會驚訝多少 IdP 搞錯這件事。
• 自訂註冊欄位：註冊時可收集角色、公司名、用途嗎？還是事後還要獨立 onboarding 流程？
• 漸進式資料補齊（progressive profiling）：可否分多次會話收集額外資料？不用一次填完所有？

登入流程#

• login_hint 支援：從行銷 email 點進來時能 pre-fill email 嗎？看似小事，實際上會讓 email 行銷轉換率從 40% 拉高到 60%。
• 組織客製認證政策：A 組織強制 SAML，B 組織用 email/password，企業租戶才強制 MFA。每租戶認證規則若需寫程式，之後每進一個客戶工程團隊都會爆肝。
• 品牌自訂：登入介面可針對不同租戶自訂嗎？不限 logo / 色彩 —— 要能全 CSS 控制、自訂域名、郵件白牌。Hosted UI / BYO UI 應該是你選，不是被迫接受的缺陷。

多數檢查表遺漏的項目#

• 靜默（silent）認證：token 過期時 app 可否自動無聲 refresh？refresh token 若也過期有備援方案嗎（例如 iframe sliding session）？
• 帳號連結：用 Google 註冊，之後用 email 登入，會不會產生兩個帳號？IdP 怎麼處理？搞砸會一堆幽靈帳號永久存在。
• 免密碼選項：magic link、passkey、WebAuthn。不是人人立刻用，但六個月內企業客戶必問。

維度三：Session 與 token 管理 —— 見真章的地方#

這裡是真正分出專業與外行的分界。Session 與 token 管理平常很無聊，爆炸時全體用戶都會被登出。

Cookie 安全性#

不性感，但絕對關鍵。

• HttpOnly、Secure、SameSite：三者必須都正確設定。沒設 HttpOnly 的 IdP 不適合上線。
• 跨子網域支援：如你有 app.yourproduct.com 跟 api.yourproduct.com，Session 能橫跨子網域嗎？怎做到的？
• 第三方 cookie 終止：Chrome 要淘汰了。IdP 沒第三方 cookie 怎處理跨域認證？如果答案是「還在開發中」，不夠格。

記住我（Remember me）、持久化 Session#

用戶要能登入狀態保持數週，不是數分鐘。但 180 天持久會話與 30 分鐘 session 風險完全不同。

請問：

• 能否獨立設定 session 長度、token 有效期？
• 有「remember me」能加長 session 但 token 依然短效？
• 能否讓敏感操作重新認證但不終結整個 Session？

Refresh token 安全性#

• Token rotation：每次使用時 IdP 會換新 token 嗎？（應該要）
• 加密儲存：refresh token at rest 有加密嗎？
• 撤銷微粒度：可否單獨撤銷某裝置會話？
• 有效期可配置：每 app 可否設不同 refresh token 的有效期？

維度四：授權模型 —— 不只是基本的 RBAC#

RBAC 是底線。沒支援 RBAC 直接淘汰。但對 B2B SaaS，僅靠 RBAC 遠遠不夠。

組織層級權限#

用戶屬於不同組織。在每組織內的權限和在平台上的權限不同。

同一個用戶可在 A 組織為 admin，在 B 為 viewer。如果 IdP 無法原生建模，你會重做一套權限系統 —— 多了個真實資訊源。

請問：

• 支援組織層級（而不只是用戶層級）定義角色？
• 單一用戶可否在多組織有不同角色？
• 當前組織 context 能嵌在 token 內？API 會知道 user 操作哪個 org？

多層級授權（auth_level）#

金融、醫療、須分權限風險的產品：不是所有已認證的 Session 都有同樣風險。

看報表？Session cookie 夠。匯款？需要 MFA 即時加強認證。

這叫「步進式認證」，需要 auth_level 這個概念在 token 裡。

請問：

• token 能有 auth_level 欄位給後端查詢？
• 能從 app 觸發步進認證，不必全程重新登入？
• auth_level 是否有自己獨立過期時間？

IdP 無原生支援，你就得自己重造輪子 —— 當初買 IdP 本來就是要避免自己造！

基於 token 的授權決策#

理想：API middleware 讀 token，直接看 org、role、auth_level 做授權決策，不依靠外部服務。

現實：多數 IdP token 只告訴你 user 是誰，允許做什麼還得查一個 API。

多一次查詢就多一個延遲，多一個依賴，多一個失效點。每秒一千請求還要過網路查授權，你不會想這樣。

維度五：遷移 —— 一票否決的標準#

沒人愛談這點：多數 IdP 導入最後不是功能不夠好，而是團隊搞不定用戶帳號遷移。

有十萬以上用戶時，遷移不是「加分」，而是「整個專案」的關鍵。

三種遷移策略（IdP 必須支援）#

1. 直接匯入密碼 hash

現有用戶密碼都經 bcrypt/argon2 等計算。IdP 能否直接匯入 hash 直接驗證？

能：用戶用舊密碼繼續登入，一切無感。最佳。

不能：全部用戶收到重設密碼 email，遷移會淘汰 30-50% 帳號。不是假設，我們見過真實案例。

2. 漸進式（lazy）遷移

不一次遷移所有用戶，誰登入才搬。首次登入查舊系統，驗證密碼後新 IdP 加帳號。後續就用新 IdP。

大用戶基數最安全，需要：

• 有自訂 auth hook 能查 legacy 系統
• 登入時動態新建帳號
• 能追蹤誰已遷移誰還沒

3. 雙寫（平行運行）

轉換期同時維護舊新 Id 系統。寫同步到兩邊，讀逐步切回新系統。可回滾，但營運複雜度暴增。

遷移紅旗#

• 「我們支援 CSV 匯入」 —— 只匯入用戶資料，不含密碼。還是要重設密碼。
• 「我們有遷移指南」 —— 仔細讀。如果寫「用戶需要新設密碼」，就是 30-50% 的帳號流失慘劇。
• 沒提 hash 相容性 —— 廠商沒經歷過大規模遷移。

請問廠商#

• 支援哪些密碼 hash 匯入？（bcrypt, argon2, scrypt, PBKDF2, 自訂？）
• 能否做漸進式遷移？
• 能否追蹤遷移進度？
• 遷移失敗怎麼回滾？
• Session 可持續不中斷登入嗎？

廠商答不出以上，代表沒做過大型遷移，請直接淘汰。

維度六：多租戶 —— 原生不等於 workaround#

B2B SaaS 必然有多租戶：你的客戶是組織，有多用戶、多角色、多權限。IdP 必須原生支持這種結構。

什麼叫「原生多租戶」#

• 組織是第一類實體：不是用戶自訂欄位，而是正規的資料結構，包括 ID、設定、會員名單。
• 各組織認證政策：A 用 SAML SSO，B 用 email/password 必 MFA，C 用 Google 工作區，一切皆可透過 UI/API 而不用寫程式。
• 邀請和管理：每組織自己的 admin 可邀請、分配角色、移除成員。IdP 處理邀請、驗證、分配流程。
• 組織 context token：用戶在組織操作時，token 有 org context。API 能判斷返回哪家 org 資料。

「自訂 metadata」workaround#

一些 IdP 無原生組織模型，叫你用自訂 user metadata（例如 user.app_metadata.org_id = "123"）。

會很快惡化：

• 用戶多組織就是陣列 metadata
• 沒內建邀請／權限流
• 無 per-org 認證政策
• Token 無 org context，要靠其他資訊猜
• 稽核日誌不知道 org

如果有人說「可用 metadata 自訂模擬組織」，那就是用 JSON 欄位存關聯式資料，撐一陣子就爛了。

請問#

• 組織模型是不是原生？
• 一個用戶可否多組織成員？
• 不同組織能設定不同登入要求？
• 組織權限／角色原生支援？
• 組織 admin 能自助管理成員？
• token 包含 org context 嗎？

維度七：AI 準備度 —— 沒人問過但很快就會用到#

一年前 AI agent 認證還不在任何檢查表裡。今天要做 AI 功能 —— copilot、agent、AI 工作流程 —— IdP 就得處理新型態「代理」身分。

為什麼 agent 須新模型#

傳統認證是「用戶」和「應用」兩個角色。OAuth2 設計也是這種。

AI agent 是第三種：

• 代理不是用戶 —— 無密碼、無 session
• 也不是純機器人 —— 它代表某用戶操作
• 代理需要範圍可控、時間有限權限
• 代理行為要有獨立 audit trail

IdP 必須支援什麼#

Token Exchange (RFC 8693)： 代理提供自己 credential ＋ 用戶授權，取得含範圍的 token。token 得記載：誰（用戶）、哪個代理、scope（權限）、到期時點。

代理為一種 client 類型： 代理須是正規 OAuth2 client（有獨立 client_id），不能是 API key 或共享 user token 越權。

委派 scope 管理： 用戶授權代理只准讀、或只允許存取某類資源。

稽核區分：稽核日誌要區分「user 做」和「代理幫 user 做」。不區分就過不了 SOC2：審計會問每筆異動是誰發生的。

MCP（Model Context Protocol）相容性#

MCP 正成為 AI agent 與工具服務互動的標準。IdP 若支援 OAuth 為 MCP server 認證，代理就能走協定安全認證（不是 API key）。

請問#

• 支援 OAuth2 Token Exchange？
• 代理可否作為獨立 client type 模型？
• token 能寫明這是誰授權哪個代理、scope？
• 稽核能區分代理與真人行為？
• 有無 MCP server 相容性或 OAuth agent-to-tool 認證支援？

廠商沒想過，代表只在做 2020 年的產品。你該規劃 2026 年用的。

維度八：非功能需求 —— 那些會讓你睡不著的事#

功能賣得動，營運才決定是否續約。

效能#

• 認證處理吞吐量：能否高峰處理每秒 100+（或甚至 1,000+）認證請求？
• token 驗證延遲：service 本地驗證 JWT（應該這樣做）亞毫秒。要 introspection API 查，P99 延遲多少？
• 規模天花板：最高每月活躍用戶（MAU）支援多少？有沒有跑過你預計的目標級別？

合規性#

• SOC2 Type II：不是 Type I。Type II 表示已連續審核過一段時期，而非只做過一次。對方只有 Type I，問 Type II 時程。
• 稽核日誌：所有登入、權限修改、管理操作都記錄。可否匯出到 SIEM？記錄不可竄改嗎？
• 資料存放地：能否指定資料儲存區域？歐盟客戶這點沒得選。

可用性#

• Uptime SLA：99.9%＝年停機 8.7 小時。99.99% 只剩 52 分鐘。授權是產品入口，這差很大。
• 故障備援：供應商掛掉時？有無備援？是否有多區部署？
• 事故紀錄：看狀態頁歷史。不看承諾，看實際。

資料可攜性#

• 用戶資料導出：能否匯出所有 user data，包括 metadata、組織成員、角色？格式是什麼？
• 標準協定支援：用標準協定（如 OIDC、SCIM）遷移到其他服務容易嗎？
• 不綁死：專有 API、客製協定、特殊 token 格式，這些越多綁得越死。標準化越多、未來能離開也更容易。

評分矩陣：最實用的評比方法#

跨各維度評估後，需要量化比較。這裡有個優先等級：

P1 — 一票否決#

P2 — 強烈建議（缺少需補大量工程）#

P3 — 重要（12 個月內需實現）#

P4 — 加分項（不影響決策）#

用法：從 P1 開始。廠商有一項 P1 不過就淘汰。再評 P2、P3 類別。P2+P3 得分高的就是答案。

常見評估錯誤#

我們反覆見到團隊犯相同錯誤，避免方式如下：

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

功能比較表只能說有無，但無法告訴你怎麼做。IdP 可能靠 user metadata 存 org_id，excel 打勾沒錯，上線就災難。

解法：每項功能都問「實作方式？」不是「有沒有這個？」

錯誤二：遷移問題到最後才處理#

團隊選定「最佳」 IdP，進開發才發現用戶不能無感遷移，只有推密碼重設一途。最後只好硬頭皮遷移或重頭再評。

解法：遷移應放第一關，不是最後一關。

錯誤三：過度依賴 demo#

廠商的 demo 都很完美。乾淨資料、無邊界案例。你的實際環境會有合併帳號、奇怪 unicode、怪 session。

解法：要 proof-of-concept 用你真實資料。匯入 1,000 個真實 user，做真實驗證流程。

錯誤四：沒找對人參與評選#

只讓平台工程師評比，他們會挑技術最清潔的。只讓產品團隊，會選整合最快的。只讓資安，會選 compliance 最多的。

解法：評估團隊要有平台工程、產品、資安。各自負責不同 P1/P2 標準。

錯誤五：沒想到以後要搬家#

廠商綁死是真的，專屬 SDK、自訂 API、特殊 token，日後超難搬家。

解法：偏好用標準協定（OIDC、OAuth2、SCIM）的 IdP。你未來會感謝自己。

FAQ#

IdP 評估通常要多久？#

如要完整包含 POC 測試，預估需 4-8 週。心急只會犯上面提的遷移漏評等錯誤。建議 2 週需求調查、2-3 週廠商評估＋ POC、1-2 週內部協調。

該自己打造 auth 嗎？#

看階段。用戶低於萬數、沒企業客戶，可以輕量 auth library。若需 SSO、多租戶、MFA、合規文件，自建成本立刻超越 IdP。見過工程團隊為此全年兩三個人在維護等同 300-500 萬台幣。

CIAM 和 workforce IAM 差在哪？#

CIAM（Customer Identity & Access Management）是產品終端用戶會碰的（註冊、登入、管理），workforce IAM 是員工用來上內部工具（Okta for Slack/Google Workspace 等）。兩者採購與評選邏輯完全不同。本指南僅談 CIAM。

開源 vs. 專有重要嗎？#

開源 IdP 有透明度（可 audit 原始碼）、可移植（可自架），有社群。專有家 UI 與維運通常優。關鍵不是「開 vs. 閉」，而是「想走時帶得走嗎？」開源資料模型、API 都公開，遷移較易。

AI agent auth 何時升級為 P1？#

已經有 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），選出能撐數年而非數月的解方。

做對的團隊有個共通點：把身分管理當基礎設施，不是寫完就忘的附屬功能。