單一登入回答的是驗證問題：Microsoft 是否依照組織政策驗證了這位使用者？它無法回答 Odoo 內部的所有授權問題。
已驗證的使用者可能需要存取銷售，但不需要會計；需要專案，但不需要薪資；或需要客戶入口網站，但不需要內部介面。這些決策仍屬於 Odoo 的責任。Microsoft Entra 群組與應用程式角色可以提供可信的輸入，讓這些決策更一致。
群組與應用程式角色各有不同用途
Microsoft Entra 群組屬於租用戶。它們可以代表部門、職能、專案或安全邊界。應用程式角色則屬於特定的應用程式註冊，用來描述對該應用程式有意義的角色。
Microsoft 的 app-role 文件 說明應用程式角色可指派給使用者或群組。當已指派的使用者登入時，Entra 可以將已授與的角色包含在 roles claim 中。Microsoft 也指出，應用程式角色與群組並非互斥。
這為 Odoo 存取設計提供兩種主要模式：
- 將穩定的 Entra 安全性群組 Object ID 直接對應到選定的 Odoo 群組。
- 在 Entra 應用程式中定義以 Odoo 為中心的應用程式角色，將使用者或群組指派到這些角色，並將產生的角色值對應到 Odoo 群組。
直接對應適合受治理的安全性群組。應用程式角色則可提供更清晰的應用程式邊界，因為其意圖會隨著應用程式註冊傳遞，而不依賴租用戶特定名稱。
先從 Odoo 的實際存取模型開始
不要一開始就把每個 Microsoft 群組都複製到 Odoo。請先從業務真正需要的 Odoo 權限開始。
列出授予實質能力的 Odoo 群組。對每一個群組，記錄：
- 此存取的業務目的。
- 負責核准的人員。
- 代表核准的 Entra 群組或應用程式角色。
- 變更應該多快反映到 Odoo，以及移除後作用中工作階段會發生什麼事。
採用最小權限原則。廣泛的部門群組雖然方便，但可能授予比每位成員所需更多的 Odoo 存取權。較小、專用於 Odoo 的安全性群組或應用程式角色，通常更容易稽核。
將身分繫結視為一項安全控制
許多系統最初會使用電子郵件地址比對既有帳戶。這很方便，尤其當 Odoo 和 Microsoft 已使用相同的公司電子郵件時。不過，這不是持久的身分識別鍵。
Microsoft 在其 ID token claims 參考文件 中警告，電子郵件地址、電話號碼和使用者主體名稱都可能變更，而且可能被重複使用。Microsoft 建議使用 sub 或 oid 這類不可變更的 claims，若需要租用戶內容則加上 tid，以便可靠識別。
較安全的模式是：
- 只接受預期的租用戶與已核准的對象。
- 在適當情況下，使用電子郵件進行受控的首次比對。
- 拒絕含糊或重複的比對。
- 在連結後儲存不可變更的 Microsoft 身分與租用戶識別碼。
- 未來登入時使用這些不可變更的值。
對於多租用戶存取，租用戶內容至關重要。同一個人在不同租用戶中可能有不同的物件識別碼，而且來自某一租用戶的存取不應默默繼承另一個租用戶相關的權限。
了解群組宣告超額的情況
群組宣告雖然方便，但不是無限的。Microsoft 文件說明 JWT 中群組 Object ID 的上限為 200 個。當使用者的成員資格超過此限制時，Entra 會省略一般的群組清單，並回傳一個超額指示器，導引應用程式查詢 Microsoft Graph。請參閱 群組超額指引。
如果整合宣稱可在沒有提升的 Microsoft Graph API 權限下進行群組對應，這一點就很重要。成員資格很多的使用者可能不會收到預期的群組宣告集合。
在依賴直接群組對應之前，請先確認超額如何處理。可選方案包括較小的應用程式專用群組、應用程式角色、宣告篩選，或使用具最小權限同意的 Graph 查詢。
登入時同步，不等於即時佈建
SSO 模組可以在使用者登入時，比對目前的 Entra claims 與已設定的 Odoo 對應。這很有用，因為存取可以在正常驗證事件期間保持一致。
但這不等於持續佈建。如果員工在 Odoo 工作階段作用中時被從 Entra 群組移除，該工作階段可能會持續到登出、到期，或其他撤銷控制生效為止。如果前員工之後從未再次登入，登入同步程序本身不會將 Odoo 帳戶封存。
Microsoft Entra ID Governance 提供生命週期工作流程，可用於加入者、調職者與離職者流程，包括停用帳戶與移除存取指派。請參閱 Microsoft 的 生命週期工作流程指引。這些功能需要 Microsoft Entra ID Governance 或 Microsoft Entra Suite 授權。
生命週期自動化可以改善來源身分狀態，但除非有整合機制消化這些變更，否則仍不會更新 Odoo。您的離職程序應明確涵蓋 Odoo 工作階段撤銷與帳戶狀態。
建立可稽核的對應模型
讓對應數量保持易於理解。對每個群組或角色，使用穩定識別碼與可讀的說明。記錄相關 Odoo 存取存在的原因、核准者，以及上次審查時間。
至少測試以下情況：
- 具有一個預期對應的既有使用者。
- 沒有已核准對應或來自不允許租用戶的使用者。
- 首次登入的新使用者。
- 已從對應群組移除或擁有大量群組成員資格的使用者。
- 重新命名的使用者，其不可變識別碼未變更。
- 已停用的 Microsoft 帳戶，且已有現有的 Odoo 工作階段。
登入事件應協助管理員診斷宣告與對應結果，同時不暴露權杖、認證或密鑰。記錄應識別連線與結果，但敏感值應予以遮蔽。
將對應與驗證原則結合
群組與角色對應會控制 Odoo 授權。Microsoft Entra 條件式存取會控制 Microsoft 是否會在目前條件下完成驗證。這兩層彼此互補。
例如，Entra 應用程式角色可對應至 Odoo 財務群組，而條件式存取則要求指派該角色的使用者使用可防網路釣魚的驗證強度。閱讀 Microsoft Entra 條件式存取如何強化 Odoo 登入，以了解驗證原則這一側。
對於客戶與合作夥伴，不要自動重用員工對應。採用不同的受眾與以入口網站為導向的設計可能更安全。請參閱 Microsoft Entra External ID for Odoo customers and partners。
將已核准的 Microsoft 存取對應至 Odoo 19
我們的 Microsoft Entra SSO for Odoo module 支援將已設定的 Entra 安全性群組 Object ID 或應用程式角色對應至選定的 Odoo 存取群組。它可在登入時同步這些對應、連結受控的現有帳戶，並依連線類型建立已核准的員工或入口網站使用者。
此模組無法取代存取治理、工作階段撤銷或文件化的超額策略。啟用對應之前，請先檢視您的群組規模、識別繫結需求與 Odoo 權限模型。若這些基礎已清楚，這個模組可提供一種引導式方式將它們連接起來。