先把 SSO 視為治理工程，而不只是登入功能
企業導入單一登入時，最容易低估的工作不是串接登入協定，而是釐清「誰可以進入哪個系統，以及何時必須失去權限」。SAML 或 OIDC 只能證明使用者完成了某種身分驗證；應用程式仍需決定如何建立本地帳號、對應組織與角色，以及帳號被停用後如何終止既有工作階段。若只完成登入跳轉，卻保留人工建帳與離職後手動停權，風險只是從密碼管理轉移到權限管理。
設計前應先盤點身分提供者、應用程式與權威資料來源。Microsoft Entra ID、Google Workspace 或其他 IdP 可能負責驗證，但員工狀態、部門與主管關係通常來自人資系統；合作夥伴則可能由 CRM 或供應商入口管理。工程團隊需要明確指定每個欄位的來源、同步方向與衝突處理方式，避免電子郵件、顯示名稱或部門資料被多個系統互相覆寫。
- 驗證：由哪個 IdP 驗證使用者，是否要求多因素驗證，以及高風險操作是否需要再次驗證。
- 授權：群組、部門、職務或應用程式內角色如何對應，哪些權限不得由登入聲明直接授予。
- 佈建：帳號何時建立，採首次登入即時建立、SCIM 同步，或由既有流程預先開通。
- 撤銷：停權後多久生效，既有權杖、工作階段、API 金鑰與行動裝置登入如何失效。
SAML 與 OIDC 的選擇取決於系統邊界
SAML 在企業 SaaS 與傳統 Web 應用中仍很常見。它以瀏覽器重新導向與簽署的 XML assertion 傳遞身分資料，成熟 IdP 通常都有完整支援。對只需要瀏覽器登入、已有 SAML 模組的既有系統而言，沿用 SAML 往往比改造驗證層更穩妥。不過，XML 簽章、憑證輪替、NameID 格式及 metadata 更新都需要嚴謹管理；若服務提供者寫死憑證，輪替時尤其容易造成中斷。
OIDC 建立在 OAuth 2.0 之上，以 ID token 描述登入結果，較適合新式 Web、行動應用、單頁應用與 API 架構。Authorization Code Flow 搭配 PKCE 通常是優先選擇，但不能把 access token 與 ID token 混用：前者授權 API，後者讓客戶端確認登入身分。驗證端必須檢查 issuer、audience、簽章、有效期限與 nonce，不能只解碼 JWT 後就信任內容。
選型不應依「哪個協定比較新」決定，而應看目標系統支援、客戶端類型、API 需求及維運能力。同一企業同時存在 SAML 與 OIDC 很正常，可由中央 IdP 統一原則；真正應避免的是每套應用自行實作密碼、MFA 與帳號恢復流程。
帳號生命週期才是長期風險所在
帳號生命週期至少涵蓋到職、調職、留職停薪、離職、外部人員到期與重新聘用。首次登入即時建立帳號雖然簡單，但只能解決建立，無法可靠處理改名、部門異動與停權。對權限敏感的系統，通常需要以 SCIM、目錄同步或事件驅動流程維護帳號狀態；若目標系統不支援標準介面，就應建立可重試、可稽核的佈建服務，而不是依賴人工清單。
身分對應應使用穩定且不重複的識別碼，例如 IdP 的 immutable subject 或員工識別碼，不宜只以電子郵件為主鍵。電子郵件可能因改名、網域調整或重新聘用而改變，也可能被重新分配。系統同時要定義重複帳號合併、舊帳號資料歸屬，以及外部身分與內部身分同名時的處理規則。
停權流程必須涵蓋登入之外的存取途徑。除了禁止取得新 token，也要評估撤銷 refresh token、清除應用程式 session、停用服務帳號、撤回個人 API 金鑰與移轉資料所有權。短效權杖可縮小撤銷延遲，但會增加更新頻率；即時撤銷能力較強，則需要額外狀態與服務可用性。這是安全、效能與營運複雜度之間的取捨。
以失敗情境設計並驗收整合
正式上線前，不只要測試正常登入，也要演練憑證過期、金鑰輪替、IdP 暫時無法使用、使用者被停權、時鐘偏差及群組聲明過大的情況。管理員應保留受嚴格保護的緊急存取帳號，但不能讓它成為日常繞過 SSO 的入口。設定變更需有雙人覆核、稽核紀錄與回復方案，避免一次錯誤的 metadata 或 redirect URI 更新鎖住所有使用者。
可觀測性也應在設計階段納入。記錄登入結果、佈建事件、角色變更與撤銷動作，但不要把完整 token、assertion 或敏感個資寫入日誌。告警應能區分設定錯誤、使用者狀態問題與 IdP 故障，讓維運人員快速定位責任邊界。驗收時則以完整生命週期腳本測試，而非只確認登入成功。若系統橫跨舊式 SAML 應用、新式 OIDC 服務與多個資料來源，由具身分治理經驗的整合團隊協助定義邊界，通常能減少後續例外流程與維運負擔。