Odoo portals give customers and partners access to relevant documents, transactions and services. That creates an identity-design question: should external users share the employee directory and access model?
Sometimes a business guest account in a workforce tenant is appropriate. At larger scale, or where a branded customer sign-in and self-service registration are required, Microsoft Entra External ID provides a dedicated customer identity and access management model.
Connecting that model to Odoo can support a cleaner boundary between internal users and portal users. The boundary still needs explicit admission, account creation and Odoo authorisation rules.
Workforce and external tenants are designed for different audiences
Microsoft defines a workforce tenant as the environment for employees, internal business applications and organisational resources. It can also contain invited business partners and guests. An external tenant is a separate configuration for applications offered to consumers and business customers. Microsoft describes the distinction in its tenant configuration guidance.
An external tenant contains its own customer directory and application registrations. External ID adds self-service registration, sign-in, password reset, account management and identity-provider federation. The External ID overview explains the dedicated model.
This separation can help an organisation avoid treating a customer as an employee simply because both need access to an Odoo service.
Choose the audience before configuring sign-in
There are at least three distinct Odoo audiences to consider:
Employees and internal users
These users normally belong in the organisation's workforce tenant. If admitted to Odoo, they generally need internal Odoo user accounts with carefully mapped access groups.
People from approved partner organisations
Some businesses want users from a defined list of customer or partner Entra tenants. A multi-tenant workforce connection with an exact tenant allow-list can be appropriate when every organisation is known and access is approved contractually.
Tenant validation is critical. Matching an email domain alone is not enough because domains and email addresses are mutable. Validate the token's tenant and immutable subject or object identifiers according to the connection design.
Customers and external users
For customer-facing applications, an External ID tenant can provide a separate directory and sign-in experience. Odoo accounts created for this audience should normally be portal users, not internal users.
These models should be configured as separate connections when their admission and Odoo account rules differ. A single broad connection is harder to reason about and easier to misconfigure.
External ID supports a customer sign-in journey
External ID user flows define customer authentication methods and information collected during sign-up. A flow is associated with registered applications to activate sign-up and sign-in. Microsoft documents this in adding an application to an External ID user flow.
External ID can support local accounts and federation with identity providers including Microsoft Entra ID and custom OpenID Connect providers. Built-in and custom attributes can be collected during sign-up, as described in Microsoft's customer attribute guidance.
Collect only information Odoo genuinely needs, and document the purpose, retention and privacy treatment of every attribute.
Default permissions help preserve separation
Microsoft states that external-tenant users begin with restricted default permissions. They can generally access applications and manage their own profile, but do not receive broad directory administration rights. See default permissions in external tenants.
That directory boundary does not automatically configure Odoo portal permissions. Odoo still controls which records a portal user can see through its own access rights and record rules. Test the portal experience with representative customer records and more than one company or account to ensure data is isolated correctly.
Do not promote a newly created external user to an internal Odoo user unless there is a separate, approved business process.
Use a modern, validated OpenID Connect flow
Microsoft supports OAuth 2.0 authorization code flow with Proof Key for Code Exchange and OpenID Connect for server-based web applications. Its authorization code flow documentation describes that supported combination.
OIDC extends OAuth 2.0 for authentication. Microsoft publishes discovery metadata, endpoint details and public signing keys. It also recommends validating the returned token and checking a nonce to reduce replay risk. See OpenID Connect on the Microsoft identity platform.
A secure integration should validate the expected issuer, audience, signature, tenant context and nonce. PKCE does not replace token validation, exact callback configuration, TLS or protection of the client secret.
Basic sign-in can request standard OIDC scopes such as openid, profile and email. Microsoft notes that these scopes are hosted on Microsoft Graph and recommends requesting only the permissions the application needs. See Microsoft identity platform scopes. A precise product claim is therefore "no high-privilege Microsoft Graph API permissions for standard sign-in," rather than a blanket claim that Graph is not involved.
Decide how external users reach Odoo
Before enabling first sign-in, define:
- Whether self-registration is open or approval is required.
- Which tenants or identity providers are admitted.
- Whether an existing Odoo portal account can be linked.
- Which immutable Microsoft identifier is stored after linking.
- Which Odoo company and partner record the user belongs to.
- Which portal groups and record rules apply.
- What happens when access is withdrawn.
- How an active Odoo session is revoked.
Automatic account creation can reduce administration, but it should occur only after the identity satisfies the connection's admission rules. A successful Microsoft authentication proves control of the accepted identity. It does not by itself prove that the person should see a particular customer's Odoo records.
Plan for customer support and recovery
External users may not have an internal help desk. Publish a support route and identify who manages the identity. Test password reset, recovery, tenant removal and changed-email scenarios. Keep diagnostic events useful but redacted.
If your immediate need is employee access, read why you should protect your Odoo instance with Microsoft SSO. For internal permissions, see centralising Odoo access with Entra groups and app roles.
Connect external audiences to Odoo 19
Our Microsoft Entra SSO for Odoo module supports separate connections for employees, approved organisations and Microsoft Entra External ID customer audiences. External ID connections create portal users by default, while workforce connections create internal users. The guided setup validates discovery information and signing keys, then requires an interactive test before Microsoft sign-in is enabled.
The module does not decide who should be admitted or which customer records they should see. Those remain business and Odoo access decisions. Review the module if you need a controlled bridge between Microsoft customer identity and an Odoo 19 portal, with audience-specific account handling rather than a single undifferentiated login path.