Odoo 入口網站可讓客戶與合作夥伴存取相關文件、交易與服務。這帶來一個身分設計問題：外部使用者是否應與員工目錄和存取模型共用？
有時，工作階段租戶中的商務訪客帳戶是合適的。若規模較大，或需要品牌化的客戶登入與自助註冊，Microsoft Entra External ID 可提供專用的客戶身分與存取管理模型。
將此模型連結至 Odoo，可在內部使用者與入口網站使用者之間建立更清楚的界線。不過，這道界線仍需要明確的准入、帳戶建立與 Odoo 授權規則。
工作階段租戶與外部租戶是為不同對象而設計
Microsoft 將工作階段租戶定義為員工、內部商業應用程式與組織資源的環境。它也可以包含受邀的商務夥伴與來賓。外部租戶則是針對提供給消費者與企業客戶的應用程式所設的獨立設定。Microsoft 在其 tenant configuration guidance 中說明了這項區別。
外部租戶擁有自己的客戶目錄與應用程式註冊。External ID 新增自助註冊、登入、密碼重設、帳戶管理與身分識別提供者同盟。Microsoft 的 External ID overview 說明了這種專用模型。
這種分離可協助組織避免因為兩者都需要存取 Odoo 服務，就把客戶當成員工來處理。
在設定登入前，先決定受眾
至少有三種不同的 Odoo 受眾需要考慮：
員工與內部使用者
這些使用者通常應屬於組織的工作階段租戶。若允許進入 Odoo，通常需要具備經過仔細對應存取群組的內部 Odoo 使用者帳戶。
來自已核准合作夥伴組織的人員
有些企業希望來自明確客戶或合作夥伴 Entra 租戶清單的使用者可登入。當每個組織都已知，且存取已透過合約核准時，使用具有精確租戶允許清單的多租戶工作階段連線可能是適當的。
租戶驗證至關重要。僅比對電子郵件網域並不足夠，因為網域與電子郵件地址都可能變更。請依照連線設計驗證權杖的租戶，以及不可變更的 subject 或 object 識別碼。
客戶與外部使用者
對於面向客戶的應用程式，External ID 租戶可提供獨立的目錄與登入體驗。為此類受眾建立的 Odoo 帳戶通常應為入口網站使用者，而非內部使用者。
當准入與 Odoo 帳戶規則不同時，這些模型應設定為不同的連線。單一、過於寬泛的連線較難理解，也較容易設定錯誤。
External ID 支援客戶登入流程
External ID 使用者流程會定義客戶驗證方法，以及註冊期間收集的資訊。流程會與已註冊的應用程式關聯，以啟用註冊與登入。Microsoft 在 adding an application to an External ID user flow 中有說明。
External ID 可支援本機帳戶，以及與身分識別提供者的同盟，包括 Microsoft Entra ID 與自訂 OpenID Connect 提供者。可在註冊期間收集內建與自訂屬性，如 Microsoft 的 customer attribute guidance 所述。
只收集 Odoo 確實需要的資訊，並為每個屬性記錄用途、保留期限與隱私處理方式。
預設權限有助於維持分離
Microsoft 指出，外部租戶使用者一開始具有受限的預設權限。一般而言，他們可以存取應用程式並管理自己的設定檔，但不會取得廣泛的目錄管理權限。請參閱 default permissions in external tenants。
該目錄邊界不會自動設定 Odoo 入口網站權限。Odoo 仍會透過自身的存取權限與記錄規則，控制入口網站使用者可看到哪些記錄。請以具代表性的客戶記錄，以及多於一家公司或帳戶來測試入口網站體驗，確保資料隔離正確。
除非有另一套已核准的業務流程，否則不要將新建立的外部使用者升級為內部 Odoo 使用者。
使用現代且已驗證的 OpenID Connect 流程
Microsoft 支援具備 Proof Key for Code Exchange 的 OAuth 2.0 授權碼流程，以及用於伺服器型網頁應用程式的 OpenID Connect。其 authorization code flow documentation 說明了這組受支援的組合。
OIDC 擴充了 OAuth 2.0 以用於驗證。Microsoft 會公布探索中繼資料、端點詳細資料與公開簽章金鑰。它也建議驗證回傳的權杖並檢查 nonce，以降低重放風險。請參閱 OpenID Connect on the Microsoft identity platform。
安全的整合應驗證預期的 issuer、audience、簽章、租戶內容與 nonce。PKCE 不會取代權杖驗證、精確的回呼設定、TLS 或客戶端密鑰保護。
基本登入可要求標準 OIDC scope，例如 openid、profile 和 email。Microsoft 指出，這些 scope 託管於 Microsoft Graph，並建議只請求應用程式需要的權限。請參閱 Microsoft identity platform scopes。因此，更精確的產品描述是「標準登入不需要高權限的 Microsoft Graph API 權限」，而不是一概聲稱 Graph 不會參與。
決定外部使用者如何進入 Odoo
在啟用首次登入之前，請先定義：
- 是否開放自助註冊，或需要核准。
- 允許哪些租戶或身分識別提供者。
- 是否可連結既有的 Odoo 入口網站帳戶。
- 連結後會儲存哪一個不可變更的 Microsoft 識別碼。
- 使用者隸屬於哪個 Odoo 公司與夥伴記錄。
- 哪些入口網站群組與記錄規則會套用。
- 當存取權被撤銷時會發生什麼事。
- 如何撤銷現有的 Odoo 工作階段。
自動建立帳戶可以減少管理工作，但只有在身分符合連線的准入規則後才應執行。成功的 Microsoft 驗證可證明已控制獲准的身分，但單憑這點無法證明該人就應該檢視特定客戶的 Odoo 記錄。
規劃客戶支援與復原
外部使用者可能沒有內部服務台。請公開支援管道，並指明由誰管理身分。測試密碼重設、復原、租戶移除，以及電子郵件變更等情境。讓診斷事件保持實用，同時遮蔽敏感資訊。
如果您目前需要的是員工存取，請閱讀 為什麼您應該使用 Microsoft SSO 保護您的 Odoo 執行個體。若是內部權限，請參閱 使用 Entra 群組與應用程式角色集中管理 Odoo 存取。
將外部受眾連接到 Odoo 19
我們的 Microsoft Entra SSO for Odoo 模組 支援為員工、已核准組織，以及 Microsoft Entra External ID 客戶受眾建立獨立連線。External ID 連線預設會建立入口網站使用者，而工作團隊連線會建立內部使用者。引導式設定會驗證探索資訊與簽署金鑰，接著在啟用 Microsoft 登入之前，要求先進行互動式測試。
此模組不會決定誰應該被允許加入，也不會決定他們應該看到哪些客戶記錄。這些仍屬於業務與 Odoo 存取決策。如果您需要在 Microsoft 客戶身分與 Odoo 19 入口網站之間建立受控橋接，且需要依受眾處理帳戶，而不是使用單一、不加區分的登入路徑，請檢閱此模組。