Odoo 门户让客户和合作伙伴可以访问相关文档、交易和服务。这就带来一个身份设计问题：外部用户是否应该共享员工目录和访问模型？
在工作区租户中使用业务访客帐户有时是合适的。在规模更大，或者需要品牌化的客户登录和自助注册时，Microsoft Entra External ID 提供了专用的客户身份与访问管理模型。
将该模型连接到 Odoo，可以帮助在内部用户和门户用户之间建立更清晰的边界。不过，这种边界仍然需要明确的准入、帐户创建和 Odoo 授权规则。
工作区租户和外部租户面向不同的对象
Microsoft 将工作区租户定义为员工、内部业务应用和组织资源所使用的环境。它也可以包含受邀的业务合作伙伴和访客。外部租户则是面向消费者和企业客户所提供应用的独立配置。Microsoft 在其 tenant configuration guidance 中说明了这种区别。
外部租户拥有自己的客户目录和应用注册。External ID 还增加了自助注册、登录、密码重置、帐户管理和身份提供商联合功能。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 支持用于基于服务器的 Web 应用的带有 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 作用域，例如 openid、profile 和 email。Microsoft 指出这些作用域托管在 Microsoft Graph 上，并建议只请求应用所需的权限。参见 Microsoft identity platform scopes。因此，更准确的产品表述是“标准登录不需要高权限的 Microsoft Graph API 权限”，而不是笼统地声称不涉及 Graph。
确定外部用户如何访问 Odoo
在启用首次登录之前，请先定义：
- 是否开放自助注册，或者是否需要审批。
- 允许哪些租户或身份提供商。
- 是否可以关联现有的 Odoo 门户帐户。
- 链接后存储的是哪个不可变的 Microsoft 标识符。
- 用户属于哪个 Odoo 公司和合作伙伴记录。
- 适用哪些门户组和记录规则。
- 撤销访问时会发生什么。
- 如何撤销一个活动的 Odoo 会话。
自动创建账户可以减少管理工作，但应仅在身份满足连接的准入规则之后进行。成功的 Microsoft 身份验证证明已控制被接受的身份，但它本身并不能证明该人员应查看某个特定客户的 Odoo 记录。
为客户支持和恢复做好规划
外部用户可能没有内部帮助台。请公布支持渠道，并明确由谁管理该身份。测试密码重置、恢复、租户移除和电子邮件变更场景。保持诊断事件有用，但需进行脱敏。
如果你当前的需求是员工访问，请阅读 为什么你应该使用 Microsoft SSO 保护你的 Odoo 实例。对于内部权限，请参阅 使用 Entra 组和应用角色集中管理 Odoo 访问。
将外部受众连接到 Odoo 19
我们的 用于 Odoo 的 Microsoft Entra SSO 模块 支持为员工、已批准组织以及 Microsoft Entra External ID 客户受众分别建立连接。External ID 连接默认创建门户用户，而工作账户连接创建内部用户。引导式设置会验证发现信息和签名密钥，然后在启用 Microsoft 登录前要求进行交互式测试。
该模块不会决定谁应被允许访问，或他们应查看哪些客户记录。这些仍然属于业务和 Odoo 访问决策。如果你需要在 Microsoft 客户身份与 Odoo 19 门户之间建立受控桥梁，并按受众分别处理账户，而不是使用单一、无差别的登录路径，请查看该模块。