Single sign-on answers an authentication question: has Microsoft verified this user according to the organisation's policy? It does not answer every authorisation question inside Odoo.

An authenticated user might need access to sales but not accounting, projects but not payroll, or a customer portal but not the internal interface. Those decisions remain Odoo responsibilities. Microsoft Entra groups and application roles can provide trusted inputs for making them more consistent.

Groups and app roles serve different purposes

Microsoft Entra groups belong to the tenant. They may represent departments, job functions, projects or security boundaries. Application roles belong to a particular app registration and describe roles that are meaningful to that application.

Microsoft's app-role documentation explains that app roles can be assigned to users or groups. When an assigned user signs in, Entra can include the granted roles in a roles claim. Microsoft also states that app roles and groups are not mutually exclusive.

This gives an Odoo access design two main patterns:

  • Map stable Entra security-group Object IDs directly to selected Odoo groups.
  • Define Odoo-focused app roles in the Entra application, assign users or groups to those roles, and map the resulting role values to Odoo groups.

Direct mapping works well with governed security groups. App roles can provide a cleaner application boundary because their intent travels with the app registration rather than depending on tenant-specific names.

Start with Odoo's actual access model

Do not begin by copying every Microsoft group into Odoo. Begin with the Odoo permissions the business genuinely needs.

List the Odoo groups that grant material capabilities. For each one, document:

  • The business purpose of the access.
  • The person accountable for approving it.
  • The Entra group or app role that represents approval.
  • How quickly a change should reach Odoo and what happens to an active session after removal.

Use the least-privilege principle. A broad department group may be convenient, but it may grant more Odoo access than every member needs. A smaller Odoo-specific security group or app role is often easier to audit.

Treat identity binding as a security control

Many systems initially match an existing account using an email address. This is convenient, especially when Odoo and Microsoft already use the same corporate email. It is not a durable identity key.

Microsoft warns in its ID token claims reference that email addresses, phone numbers and user principal names can change and can be reused. Microsoft recommends immutable claims such as sub or oid, with tid where tenant context is required, for reliable identification.

A safer pattern is:

  1. Admit only an expected tenant and approved audience.
  2. Use email for a controlled first-time match where appropriate.
  3. Refuse ambiguous or duplicate matches.
  4. Store the immutable Microsoft identity and tenant identifiers after linking.
  5. Use those immutable values for future sign-ins.

For multi-tenant access, tenant context is essential. The same person can have different object identifiers in different tenants, and access from one tenant should not silently inherit permissions associated with another.

Understand the group-claim overage case

Group claims are convenient, but they are not unlimited. Microsoft documents a limit of 200 group Object IDs in a JWT. When a user's membership exceeds the limit, Entra omits the normal group list and returns an overage indicator that directs the application to query Microsoft Graph. See the groups overage guidance.

This matters if an integration advertises group mapping without elevated Microsoft Graph API permissions. A user with extensive group membership may not receive the expected group claim set.

Before relying on direct group mapping, confirm how overage is handled. Options include smaller app-specific groups, app roles, claim filtering, or a Graph-based lookup with least-privilege consent.

Synchronisation at sign-in is not real-time provisioning

An SSO module can compare current Entra claims with configured Odoo mappings when a user signs in. That is useful because access can be aligned during a normal authentication event.

It is not the same as continuous provisioning. If an employee is removed from an Entra group while an Odoo session is active, that session may continue until logout, expiry or another revocation control applies. If a former employee never signs in again, a sign-in synchronisation process does not itself archive the Odoo account.

Microsoft Entra ID Governance offers Lifecycle Workflows for joiner, mover and leaver processes, including disabling accounts and removing access assignments. See Microsoft's Lifecycle Workflows guidance. These capabilities require Microsoft Entra ID Governance or Microsoft Entra Suite licensing.

Lifecycle automation can improve the source identity state, but it still does not update Odoo unless an integration consumes the change. Your offboarding procedure should explicitly cover Odoo session revocation and account state.

Build an auditable mapping model

Keep the number of mappings understandable. For each group or role, use a stable identifier and a human-readable description. Record why the associated Odoo access exists, who approved it and when it was last reviewed.

Test at least these cases:

  • Existing user with one expected mapping.
  • User with no approved mapping or a disallowed tenant.
  • New user admitted for first sign-in.
  • User removed from a mapped group or with many group memberships.
  • Renamed user whose immutable identity has not changed.
  • Disabled Microsoft account with an existing Odoo session.

Sign-in events should help administrators diagnose claim and mapping outcomes without exposing tokens, credentials or secrets. Logs should identify the connection and result, but sensitive values should be redacted.

Combine mapping with authentication policy

Group and role mapping controls Odoo authorisation. Microsoft Entra Conditional Access controls whether Microsoft will complete authentication under the current conditions. The two layers complement each other.

For example, an Entra app role can map to an Odoo finance group, while Conditional Access requires a phishing-resistant authentication strength for the users assigned that role. Read how Microsoft Entra Conditional Access strengthens Odoo sign-in for the authentication-policy side.

For customers and partners, do not automatically reuse employee mappings. A separate audience and portal-oriented design may be safer. See Microsoft Entra External ID for Odoo customers and partners.

Map approved Microsoft access into Odoo 19

Our Microsoft Entra SSO for Odoo module supports mapping configured Entra security-group Object IDs or application roles to selected Odoo access groups. It can synchronise those mappings at sign-in, link a controlled existing account, and create approved workforce or portal users according to the connection type.

The module does not replace access governance, session revocation or a documented overage strategy. Review your group scale, identity-binding requirements and Odoo permission model before enabling mappings. If those foundations are clear, the module provides a guided way to connect them.