Identity & Access Management: SSO, MFA & Role-Based Access in Odoo

Identity is the new perimeter. When your employees access Odoo ERP from home offices, branch locations, and mobile devices, the traditional network boundary becomes meaningless. What remains constant is identity: every access request comes from a specific user, on a specific device, at a specific time, requesting access to a specific resource. Managing these identity signals effectively is the foundation of modern enterprise security.

Verizon's Data Breach Investigations Report consistently identifies credential-related attacks as the primary vector in over 60% of breaches. For Odoo ERP systems that centralize financial data, customer records, HR information, and supply chain intelligence, a single compromised credential can expose the entire operational backbone of the business.

Key Takeaways

• Centralized SSO through an identity provider eliminates password sprawl and provides a single point for access enforcement and revocation
• Hardware security keys (WebAuthn/FIDO2) provide the strongest MFA, but TOTP authenticator apps offer the best balance of security and usability for most deployments
• Odoo's group-based access control system supports granular RBAC when properly configured with custom groups beyond the default User/Manager roles
• Quarterly access reviews reduce excessive privilege accumulation and catch orphaned accounts before they become attack vectors

---

Centralized Identity Management

Centralized identity management connects all your business applications to a single identity provider (IdP) that serves as the authoritative source for user authentication and, in many cases, authorization. Instead of each application maintaining its own user database and password, users authenticate once through the IdP and receive access to all authorized applications.

Identity Provider Options

| Provider | Type | Best For | SSO Protocols | MFA Options | Pricing | |----------|------|----------|---------------|-------------|---------| | Authentik | Open-source, self-hosted | Full control, privacy-conscious orgs | SAML, OIDC, LDAP, SCIM | TOTP, WebAuthn, SMS, Duo | Free (self-hosted) | | Keycloak | Open-source, self-hosted | Java/enterprise ecosystems | SAML, OIDC, LDAP | TOTP, WebAuthn | Free (self-hosted) | | Okta | Cloud SaaS | Large enterprises, broad app catalog | SAML, OIDC, SCIM | TOTP, Push, WebAuthn, SMS | $6-15/user/month | | Azure AD (Entra ID) | Cloud SaaS | Microsoft-heavy environments | SAML, OIDC, WS-Fed | Authenticator, FIDO2, SMS | Included with M365 | | Google Workspace | Cloud SaaS | Google-heavy environments | SAML, OIDC | Authenticator, Titan Key | Included with Workspace | | JumpCloud | Cloud SaaS | SMBs, device management | SAML, OIDC, LDAP, RADIUS | TOTP, Push, WebAuthn | $7-24/user/month |

For organizations running Odoo ERP, the choice typically comes down to Authentik (maximum control, no licensing costs, strong OIDC support) or Okta/Azure AD (managed service, extensive app marketplace, zero operational overhead).

SSO Protocols: SAML vs OIDC

SAML 2.0 (Security Assertion Markup Language) is the established enterprise SSO protocol. It uses XML-based assertions exchanged between the IdP and service provider (SP). SAML is widely supported by enterprise applications and provides rich attribute mapping.

OIDC (OpenID Connect) is the modern protocol built on top of OAuth2. It uses JSON-based tokens (JWTs) and RESTful endpoints. OIDC is simpler to implement, better suited for APIs and SPAs, and increasingly preferred for new integrations.

| Aspect | SAML 2.0 | OIDC | |--------|----------|------| | Token format | XML assertions | JSON Web Tokens (JWT) | | Transport | HTTP POST/Redirect bindings | HTTPS with JSON | | Best for | Enterprise web apps | APIs, SPAs, mobile apps | | Implementation complexity | Higher | Lower | | Session management | IdP-initiated or SP-initiated | Standard OAuth2 flows | | Odoo support | Via contrib modules | Native (OAuth2 provider module) |

Configuring SSO for Odoo

Odoo supports OAuth2/OIDC authentication natively through its OAuth2 provider configuration. The setup involves:

1. Create an OAuth2/OIDC application in your identity provider (Authentik, Okta, etc.) with the redirect URI pointing to your Odoo instance (https://your-odoo.com/auth_oauth/signin)
2. Configure the OAuth provider in Odoo under Settings > General Settings > OAuth Providers with the client ID, client secret, authorization URL, token URL, and userinfo URL
3. Map user attributes --- Ensure the IdP sends email, name, and any custom attributes needed for group mapping
4. Enable auto-account creation if you want new SSO users to be provisioned automatically in Odoo
5. Disable direct login (optional but recommended) to force all authentication through SSO

For advanced deployments, SCIM (System for Cross-domain Identity Management) can synchronize user provisioning and deprovisioning between the IdP and Odoo, ensuring that terminated employees lose Odoo access immediately when disabled in the IdP.

---

Multi-Factor Authentication (MFA)

MFA adds a second verification factor beyond the password, blocking 99.9% of automated credential attacks according to Microsoft's research. For Odoo systems containing financial and HR data, MFA is not optional --- it is the single highest-impact security control available.

MFA Method Comparison

| Method | Security | Usability | Cost | Phishing Resistant | |--------|----------|-----------|------|-------------------| | WebAuthn/FIDO2 (hardware key) | Excellent | Good | $25-70/key | Yes | | WebAuthn/FIDO2 (platform) | Excellent | Excellent | Free (built into device) | Yes | | TOTP Authenticator App | Good | Good | Free | No (but resistant to remote attacks) | | Push Notification | Good | Excellent | $3-6/user/month | No (MFA fatigue attacks) | | SMS/Voice OTP | Fair | Good | $0.01-0.05/message | No (SIM swapping, SS7 attacks) | | Email OTP | Poor | Fair | Free | No (email compromise negates benefit) |

Recommended MFA Strategy

For administrators and privileged users: Require WebAuthn/FIDO2 hardware security keys (YubiKey 5 series, Google Titan). These are phishing-resistant because the cryptographic challenge is bound to the origin domain --- a phishing site cannot intercept the authentication.

For standard business users: Require TOTP authenticator apps (Google Authenticator, Microsoft Authenticator, Authy). These provide strong protection against credential stuffing and remote attacks at zero cost per user.

For all users: Eliminate SMS-based OTP. SIM swapping attacks cost as little as $100 to execute and completely bypass SMS-based MFA. If SMS must be supported as a fallback, combine it with device trust verification.

Implementing MFA in Odoo

Odoo 17+ includes built-in TOTP support. Enable it under Settings > Permissions > Two-Factor Authentication. For WebAuthn support and more advanced MFA policies (conditional MFA based on location, device, or risk), implement MFA at the identity provider level:

• Authentik --- Configure MFA policies per application. Require WebAuthn for admin access, TOTP for standard access. Support recovery codes for account lockout prevention.
• Okta --- Adaptive MFA adjusts requirements based on risk signals. Low-risk logins may require only a push notification. High-risk logins (new device, unusual location) require hardware key.
• Azure AD --- Conditional Access policies enforce MFA based on user risk, sign-in risk, device compliance, and application sensitivity.

The advantage of IdP-level MFA is that it applies across all connected applications (Odoo, email, file sharing, etc.) from a single configuration point.

---

Role-Based Access Control in Odoo

Odoo implements RBAC through a group-based access control system. Every module defines access groups, and users are assigned to groups that determine their permissions. Understanding and properly configuring this system is essential for enforcing least-privilege access.

Odoo Access Control Architecture

Odoo's access control operates at four levels:

Menu access. Controls which menu items are visible to a user. This is cosmetic --- it hides menu items but does not enforce access at the data level.

Object access (ir.model.access). Controls CRUD operations (create, read, update, delete) on entire database models. Defined per group, per model.

Record rules (ir.rule). Controls which records within a model a user can access. This is the fine-grained access control that enforces data isolation. Record rules use domain filters (e.g., [('department_id', '=', user.department_id)]).

Field access. Controls access to specific fields within a model. Sensitive fields (salary, cost price, margin) can be restricted to specific groups.

Designing Custom Access Groups

The default User and Manager roles in most Odoo modules are too broad for security-conscious deployments. Design custom groups that match your organizational structure:

| Module | Default Groups | Recommended Custom Groups | |--------|---------------|--------------------------| | Sales | User, Manager | Sales Rep, Sales Team Lead, Regional Manager, VP Sales | | Accounting | Invoicing, Accountant, Adviser | AP Clerk, AR Clerk, Staff Accountant, Controller, CFO | | HR | Officer, Manager | HR Assistant, HR Generalist, HR Manager, CHRO | | Inventory | User, Manager | Warehouse Worker, Shift Supervisor, Warehouse Manager, Logistics Director | | Purchase | User, Manager | Purchase Requester, Buyer, Purchase Manager, Procurement Director |

Record Rules for Multi-Tenancy

For multi-company Odoo deployments, record rules must enforce data isolation between companies:

• Every model with company-sensitive data must have a record rule filtering by company_id
• Cross-company access should be explicitly granted only to holding company administrators
• Test record rules by logging in as users from different companies and attempting to access cross-company records
• Audit record rules quarterly to ensure new custom models include proper company isolation

For organizations using Odoo as part of a broader business platform security strategy, RBAC in Odoo should align with the access control policies enforced across all connected systems.

---

Access Review and Governance

Access control is not a set-and-forget configuration. Without regular review, permissions accumulate over time as employees change roles, take on additional responsibilities, and retain access from previous positions. This "privilege creep" creates excessive access that increases the blast radius of credential compromise.

Quarterly Access Review Process

1. Generate access reports listing all users, their assigned groups, and last login dates
2. Identify anomalies --- Users with admin access who are not IT staff, users with access to modules unrelated to their role, accounts that have not logged in for 90+ days
3. Review with managers --- Each department head reviews and confirms the access assignments for their team
4. Revoke excess privileges --- Remove group assignments that are no longer needed
5. Disable dormant accounts --- Deactivate accounts with no login activity for 90+ days
6. Document decisions --- Record the review date, reviewer, and any changes made for audit evidence

Automated Access Governance

For larger deployments, automate access governance using:

• SCIM provisioning to automatically create and update Odoo user accounts when employees are hired, change roles, or are terminated in the HR system
• Group mapping from IdP groups to Odoo groups, so role changes in the identity provider automatically adjust Odoo permissions
• Access certification campaigns triggered on a schedule (quarterly) or by events (role change, department transfer)
• Orphaned account detection alerting when accounts exist in Odoo but not in the IdP (indicating manual creation that bypassed governance)

Privileged Access Management

Administrative accounts in Odoo (Settings group, Technical features group, database manager) require additional controls:

• Separate admin accounts --- Administrators use their standard account for daily work and a separate privileged account for administrative tasks
• Just-in-time (JIT) access --- Administrative access is granted on request, for a specific duration, with approval workflow
• Session recording --- Administrative sessions are logged and recorded for audit purposes
• Break-glass procedures --- Emergency access procedures for situations where the normal privileged access workflow is unavailable

---

Odoo-Specific IAM Security Hardening

Beyond standard RBAC and SSO, Odoo deployments benefit from platform-specific hardening:

XML-RPC and JSON-RPC Access

Odoo exposes XML-RPC and JSON-RPC APIs for external integrations. These APIs bypass the web UI authentication and must be secured separately:

• Restrict API access by IP using firewall rules or reverse proxy configuration
• Use API keys rather than user credentials for integration authentication
• Rate limit API endpoints to prevent credential stuffing and brute force attacks
• Monitor API authentication failures and alert on anomalous patterns
• Disable unused API protocols --- If you only use JSON-RPC, disable XML-RPC

Database Manager Security

Odoo's database manager (/web/database/manager) allows creating, duplicating, deleting, and restoring databases. In production:

• Set a strong database manager password (or disable it entirely with --no-database-list)
• Restrict access to the database manager URL via reverse proxy rules
• Use --database flag to specify the exact database, preventing database enumeration

Session Security

• Configure session_timeout to automatically expire idle sessions (recommended: 30-60 minutes for standard users, 15 minutes for privileged users)
• Enable secure and httpOnly flags on session cookies
• Implement concurrent session limits to prevent credential sharing and detect compromise

---

Frequently Asked Questions

Can I use SSO with Odoo Community Edition?

Odoo Community Edition supports OAuth2 authentication through the auth_oauth module, which enables basic SSO with providers like Google and GitHub. For enterprise-grade SSO with SAML, SCIM provisioning, and advanced attribute mapping, Odoo Enterprise Edition provides additional modules. Alternatively, you can achieve similar functionality in Community Edition using reverse proxy authentication through Authentik or Keycloak, where the proxy handles SSO and passes the authenticated identity to Odoo via headers.

What happens if the identity provider goes down?

If the IdP is unavailable, users cannot authenticate through SSO. This is why break-glass procedures are critical. Maintain at least one local administrative account in Odoo with a strong, unique password stored in a physical safe or hardware security module. This account bypasses SSO and allows administrators to access the system during IdP outages. For high-availability deployments, configure IdP clustering or a secondary IdP with automatic failover.

How do I migrate existing Odoo users to SSO?

The migration process involves matching existing Odoo user accounts with IdP identities, typically by email address. Create users in the IdP, configure SSO in Odoo, and update existing user records to link with their OAuth provider. Users will authenticate through SSO on their next login. Plan for a transition period where both local and SSO authentication are available, then disable local authentication once all users have successfully migrated.

Should I enforce MFA at the IdP level or in Odoo directly?

Enforce MFA at the IdP level. This provides consistent MFA across all connected applications (not just Odoo), centralizes MFA policy management, and enables advanced features like conditional MFA and risk-based authentication. Odoo's built-in TOTP is suitable only as a standalone deployment without an IdP.

How do I handle access for external partners and vendors?

Create a dedicated "Portal" or "External User" group in Odoo with restricted record rules that limit visibility to only the partner's own data. Use the IdP's external identity features (Authentik's "Sources" or Okta's "Customer Identity") to manage external user authentication separately from employee authentication. Apply stricter MFA requirements and session timeouts for external users. Conduct vendor security assessments before granting any access.

---

What Is Next

Identity and access management is the cornerstone of a zero trust security architecture. Start by consolidating authentication through a centralized identity provider, enforce MFA for all users, configure granular RBAC in Odoo beyond the default roles, and implement quarterly access reviews. Each step materially reduces your risk of credential-based attacks.

ECOSIRE implements enterprise-grade IAM across every Odoo ERP deployment, including SSO integration with Authentik, role-based access design, and security hardening. Our OpenClaw AI platform extends identity-aware security to AI-powered applications. Contact our team to build a secure identity foundation for your business.

---

Published by ECOSIRE --- helping businesses scale with AI-powered solutions across Odoo ERP, Shopify eCommerce, and OpenClaw AI.