繁體中文（香港）

身份管理
企業
認證

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

一個根據真實企業需求建立的實用 IdP 評估框架。涵蓋協定深度、遷移、多租戶、AI 準備度，以及大多數清單忽略的標準。

Yijun

Developer

2/13/2026

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

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

這不是那種文章。

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

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

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

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

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

協定深度比功能數更重要。 支援「OAuth2」不代表什麼。有哪些授權模式？能否自訂 token claims？你能不能讓自己變成 OIDC provider？
遷移能力是最被低估的關鍵。 如果你無法在不強制重設密碼的情況下把現有用戶遷移過來，這個 IdP 基本不能用——其他再好也沒用。
多租戶必須原生支援，不能只是補丁方案。 如果組織架構和每租戶設定都要靠 workaround，你會永遠在和系統搏鬥。
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 管理超無聊但是出事時會一次登出所有用戶。

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

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——底線，不通過即出局

標準	為什麼屬於 P1
密碼 hash 可匯入或支援漸進遷移	不會遷不能用
Authorization Code + PKCE	基本安全門檻
原生組織模型	做 B2B SaaS 必備
SOC2 Type II 或明確規劃	企業客戶都會問
99.9% 以上 SLA	認證掛斷產品掛

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

標準	為什麼屬於 P2
自訂 JWT claims	避免每次都查權限
每 org 認證政策	企业客戶快速上線
org 角色與 token 都能分級	多租戶授權控管
Token 輪換與撤銷	安全基本動作
可選代管 UI/自製 UI	不同場景彈性

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

標準	為什麼屬於 P3
Token Exchange (RFC 8693)	AI agent 認證
OIDC Provider 能力	合作夥伴 federation
上提認證/多層級 auth_level	金融/高風險操作
SCIM 目錄同步	企業客戶連動
Passkey/WebAuthn	無密碼方向

P4——加分但非關鍵

標準	為什麼屬於 P4
內建分析 dashboard	審計 log 可取代
White-label email 模板	小便利功能
flow builder	小便利功能
超過前五大社交鏈接	長尾平台用

**用法：**從 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 當成基礎設施不是一次性功能。

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

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

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

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

OIDC Provider 能力#

JWT 自訂化#

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

註冊流程#

登入流程#

多數清單忽略的重點#

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

Cookie 安全#

切換帳號與長存 sessions#

Refresh token 安全#

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

組織範圍的權限#

多層級認證（auth_level）#

Token 做授權決策#

面向五：遷移——一切的關鍵#

三種遷移策略（以及必須支援的方式）#

遷移的警訊#

你要問：#

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

什麼叫「原生多租戶」#

「自訂 metadata」workaround#

你要問：#

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

為什麼 agent 打破傳統模式#

IdP 必須支援什麼#

MCP（Model Context Protocol）兼容性#

你要問：#

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

效能#

合規#

穩定性#

資料可攜#

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

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

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

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

P4——加分但非關鍵#

常見評估錯誤#

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

錯誤二：忘記遷移問題#

錯誤三：看 demo 被騙#

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

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

常見問題 FAQ#

IdP 評估要多久？#

要不要自建 auth？#

CIAM 跟 workforce IAM 有什麼不同？#

開源 IdP 比私有好在哪？#

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

各家報價模型很難比怎麼辦？#

重點總結#

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

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

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

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

OIDC Provider 能力#

JWT 自訂化#

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

註冊流程#

登入流程#

多數清單忽略的重點#

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

Cookie 安全#

切換帳號與長存 sessions#

Refresh token 安全#

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

組織範圍的權限#

多層級認證（auth_level）#

Token 做授權決策#

面向五：遷移——一切的關鍵#

三種遷移策略（以及必須支援的方式）#

遷移的警訊#

你要問：#

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

什麼叫「原生多租戶」#

「自訂 metadata」workaround#

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

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

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

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

OIDC Provider 能力

JWT 自訂化

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

註冊流程

登入流程

多數清單忽略的重點

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

Cookie 安全

切換帳號與長存 sessions

Refresh token 安全

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

組織範圍的權限

多層級認證（auth_level）

Token 做授權決策

面向五：遷移——一切的關鍵

三種遷移策略（以及必須支援的方式）

遷移的警訊

你要問：

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

什麼叫「原生多租戶」

「自訂 metadata」workaround

你要問：

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

為什麼 agent 打破傳統模式

IdP 必須支援什麼

MCP（Model Context Protocol）兼容性

你要問：

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

效能

合規

穩定性

資料可攜

評估矩陣：實用打分框架

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

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

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

P4——加分但非關鍵

常見評估錯誤

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

錯誤二：忘記遷移問題

錯誤三：看 demo 被騙

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

錯誤五：忘了有天會換家

常見問題 FAQ

IdP 評估要多久？

要不要自建 auth？

CIAM 跟 workforce IAM 有什麼不同？

開源 IdP 比私有好在哪？

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

各家報價模型很難比怎麼辦？

重點總結

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

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

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

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

OIDC Provider 能力

JWT 自訂化

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

註冊流程

登入流程

多數清單忽略的重點

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

Cookie 安全

切換帳號與長存 sessions

Refresh token 安全

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

組織範圍的權限

多層級認證（auth_level）

Token 做授權決策

面向五：遷移——一切的關鍵

三種遷移策略（以及必須支援的方式）

遷移的警訊

你要問：

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

什麼叫「原生多租戶」

「自訂 metadata」workaround