Which self-hosted CRM with SSO fits your identity provider
If your staff must sign in with the corporate identity provider and you want to avoid a paid tier, the free core of SuiteCRM offers SAML and LDAP, and the free core of EspoCRM offers OpenID Connect and LDAP. Twenty lists SSO for its paid Organization and Enterprise plans, so it only fits this requirement if you accept a per-user subscription on top of self-hosting. Frappe CRM and Krayin are not covered by the SSO facts used for this page, so confirm their login options directly with each project before you shortlist them.
For SuiteCRM 8, the choice of protocol is set by the AUTH_TYPE value, either ldap or saml. If your identity provider is SAML-based, check the logout behavior first: the SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout, so an employee who signs out at the identity provider keeps a live CRM session. Plan a session timeout or a compensating control, and confirm the current behavior against the SuiteCRM 8.7.0+ SAML configuration reference. Also note that SuiteCRM 7 and 8 are separate products, so SSO set up on one does not carry over to the other.
For EspoCRM, OIDC sign-in can create users on first login and map identity provider groups to EspoCRM teams, which reduces manual account administration. Two checks matter before rollout: EspoCRM's own two-factor authentication is not compatible with OIDC, so your identity provider must enforce MFA, and a fallback login method must be defined for administrators. Confirm how backchannel logout behaves with your provider. For LDAP with Active Directory or OpenLDAP, test group-based access in a staging instance before you cut over.
Which CRM to shortlist for each identity setup
This table maps common identity setups to the open-source CRM most likely to fit, with the condition under which each fit holds. Read each row against your own identity provider, hosting stack and compliance obligations before shortlisting.
| Scenario | Best fit | Why, and the condition it depends on |
|---|---|---|
| Active Directory shop wanting directory sign-in | SuiteCRM or EspoCRM | Both support LDAP, and EspoCRM's docs describe Active Directory and OpenLDAP. Holds if your directory is reachable from the CRM host and you confirm group mapping and account lifecycle with your own AD administrators. |
| Entra ID or Okta shop needing OIDC or SAML | EspoCRM (OIDC) or SuiteCRM (SAML) | EspoCRM supports OpenID Connect with optional user creation on first login and team mapping. SuiteCRM 8 supports SAML, but its 8.7.0+ implementation does not support IdP-initiated logout, so confirm this is acceptable. |
| Team that wants SSO without buying a plan | SuiteCRM or EspoCRM | Both list SSO features in the free self-hosted core. EspoCRM's own 2FA is not compatible with OIDC, so plan MFA at the identity provider. Confirm the exact auth method against your provider's configuration. |
| Team that already runs PostgreSQL and Redis | Twenty | Twenty's self-hosted stack is a server, a worker, PostgreSQL and Redis, with at least 2 GB of RAM. Holds if you can run those components, but SSO is listed only on the Organization and Enterprise plans. |
| Regulated team needing SCIM or IP allow-listing | Twenty Enterprise, or confirm with each vendor | Twenty lists SCIM provisioning and IP allow-listing only on Enterprise. Neither SuiteCRM nor EspoCRM was confirmed here for SCIM or IP allow-listing, so ask each vendor and test before deciding. |
| Team with existing PHP and MySQL or MariaDB hosting skills | SuiteCRM or EspoCRM | Both are PHP applications on MySQL or MariaDB. This fit holds if your operators already patch that stack and can own the identity connector configuration. |
| Team needing SSO on Odoo CRM or Frappe CRM | Confirm with each vendor | No identity connector details for Odoo CRM or Frappe CRM were supplied here. Check their documentation and test sign-in in staging before shortlisting either. |
Each CRM and its SSO position in brief
Each card below covers one open-source CRM, its license, the release line where a fact is supplied, the sign-in methods it documents, and the condition under which it suits an identity-led rollout. Read the cards together with the sign-in details, since a paid tier can change the answer for some products.
SuiteCRM
SuiteCRM is licensed under AGPL-3.0 and runs two release lines, SuiteCRM 8 (latest v8.10.2) and SuiteCRM 7 (latest v7.15.2). SuiteCRM 8 supports sign-in through LDAP and SAML without a paid tier. The SAML implementation in 8.7.0 and later does not support IdP-initiated logout, so signing out at the identity provider leaves the SuiteCRM session open. Confirm that behavior against your session policy before you choose it for an identity-led rollout.
EspoCRM
EspoCRM is licensed under AGPL-3.0 and its current line is 10.0. The documentation describes OpenID Connect sign-in since version 7.3, with optional user creation on first login, mapping of identity provider groups to teams, and backchannel logout. LDAP, including Active Directory and OpenLDAP, is also documented. EspoCRM's own two-factor authentication is not compatible with OIDC, so plan where second factors are enforced before you rely on it.
Twenty
Twenty's open-source core is mostly AGPL-3.0 with an additional application exception, and files marked with an Enterprise license header are commercial. Its pricing page lists SAML or OIDC SSO, row-level permissions and audit logs on the Organization plan, so single sign-on is not part of the free self-hosted core. A team that needs SSO without a paid plan should not treat Twenty as a fit. Also plan for PostgreSQL and Redis alongside the server and worker.
Frappe CRM
Frappe CRM is AGPL-3.0 licensed and built on the Frappe Framework, which is the same framework that underpins ERPNext. Confirm its SSO options, such as which identity protocols it supports and whether they depend on Frappe Framework settings, against its own documentation before you shortlist it. Because it is tied to the Frappe stack, the framework's authentication configuration and upgrade path become part of your identity design.
Krayin
Krayin is a Laravel-based CRM option that some teams evaluate for lighter deployments. Its license and SSO support must be confirmed from its own documentation before you rely on either. Ask the project which sign-in methods the current release supports natively, whether SAML or OIDC is available, and whether any identity feature depends on custom code you would have to maintain.
What each CRM's SSO covers in practice
SuiteCRM 8 selects one login mode per instance through the AUTH_TYPE setting. The LDAP mode uses the Symfony Security LDAP authenticators, and the SAML mode uses the nbgrp onelogin-saml-bundle. Your team picks the mode that matches your directory or identity provider and configures only that path. SuiteCRM 7 has its own login behavior, so confirm which release line you run before reading the SSO steps.
- LDAP mode: Set
AUTH_TYPE=ldap, then supply the bind account, search base and user attribute mapping described in the LDAP configuration reference. The SuiteCRM host must reach the directory over the network path you approve. - SAML mode: Set
AUTH_TYPE=saml. Register SuiteCRM as a service provider with your identity provider, and exchange entity IDs, signing certificates and assertion endpoints. - Attribute matching: Confirm which username and email attributes your identity provider sends, because user matching depends on them.
- Logout gap: From 8.7.0, the SAML implementation does not support IdP-initiated logout or POST binding to the logout service. Ending a session at the identity provider leaves the SuiteCRM session open, so plan a session timeout or a user procedure.
Test the chosen mode, the attribute mapping and the logout behavior on a staging instance before cutover, and record the results for your access review.
EspoCRM supports OpenID Connect sign-in since version 7.3, and its documentation also describes LDAP authentication for Active Directory and OpenLDAP. The OIDC option includes optional user creation on first login, mapping of identity provider groups to EspoCRM teams, backchannel logout and a fallback login method. Your identity team needs to decide several of these settings before go-live, because they control who can sign in and what access they receive.
- Client registration: Register EspoCRM as an OIDC client at your identity provider, then enter the issuer, client ID and secret in the administration settings. Confirm the exact fields against the OIDC documentation for your release.
- First-login creation: Decide whether accounts are created on first sign-in or pre-provisioned. Automatic creation lowers administrative work but widens who can reach a new account.
- Group-to-team mapping: The identity provider must send a group claim in the token. Confirm the claim name and that group membership is included.
- Backchannel logout and fallback: Backchannel logout ends EspoCRM sessions when the identity provider signals it. Keep a fallback login method for identity provider outages and limit who may use it.
- Multi-factor authentication: EspoCRM's own two-factor authentication is not compatible with OIDC, so enforce MFA at the identity provider.
For Active Directory or OpenLDAP, confirm the bind credentials and test group lookups with a staging account before enabling the option for all users.
Twenty's free open-source core can be self-hosted at no license cost, but its pricing page lists SSO on the Organization and Enterprise plans rather than in the free core. The Organization plan lists SAML or OIDC SSO alongside row-level permissions and audit logs. Enterprise adds SCIM provisioning and IP allow-listing. If your identity policy requires SSO, the licensing decision comes before the architecture decision, and the team should cost it with the vendor.
- Plan requirement: Confirm in writing which plan and license terms apply to your self-hosted deployment and how SSO is enabled under them.
- Protocol choice: Organization lists SAML or OIDC. Choose the protocol your identity provider supports best, then confirm it in your version.
- Provisioning: SCIM provisioning is listed for Enterprise only. On Organization, plan for how accounts are created, changed and removed, and confirm that process with the vendor.
- Role alignment: Row-level permissions also sit on the Organization plan. Plan how identity provider groups map to workspace roles, and confirm how group membership reaches those roles.
- Hosting footprint: The Docker Compose guide runs a server, a worker, PostgreSQL and Redis, and the identity provider connection adds to that operating surface.
Ask for the SSO plan, protocol support and provisioning scope in writing before you compare the total cost of ownership with the other options.
This tab covers two products for which this page has no researched SSO facts. Treat them as open questions until the project documentation and a staging test confirm what you need. Frappe CRM runs on the Frappe Framework, so its sign-in behavior may depend on the framework's login layer or on an additional app. Krayin's authentication options need the same check against its own documentation and release history.
- Authentication layer: Confirm whether SSO comes from the framework's core login features, a maintained app or custom code, and who supports each part.
- Protocols: Confirm by name whether SAML, OIDC or LDAP is supported, and whether user creation on first login exists.
- Group mapping: Confirm how identity provider groups or roles map to CRM roles and whether that mapping is configurable without code changes.
- Logout behavior: Confirm whether ending a session at the identity provider also ends the CRM session. This differed in SuiteCRM 8, so do not assume the behavior carries over.
- Maintenance: Review each release history and the maintainer of any SSO add-on before you depend on it for access control.
Until these points are confirmed in the project's own documentation and in a staging test with your identity provider, do not count either product as SSO-ready for your environment.
Where SSO stops: logout, two-factor and provisioning gaps
Before committing to any of these CRMs, a security lead should test where single sign-on stops covering the session. The first gap is logout. The SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing a user out at the identity provider does not end the SuiteCRM session. For a leaver, a disabled account in the directory may not close a CRM session that is already open. Run a test in staging: sign in through the identity provider, sign out there, then confirm whether the SuiteCRM session still answers. Then set a session lifetime that your policy accepts and document the result, using the SAML configuration reference for the settings that apply to your version. Ask the vendor or your integrator to confirm the behavior on the exact release you plan to run.
The second gap is two-factor authentication. EspoCRM's own two-factor login is not compatible with OIDC, so if you sign in through an identity provider, the second factor has to come from that provider. Confirm that your identity provider enforces MFA for every CRM group, including administrators, and that no fallback login method bypasses it. The EspoCRM OIDC documentation describes a fallback login method, which is useful for recovery but is also a path that needs its own control. Decide who may use it, how it is logged and how it is switched off. Twenty's SSO sits on its paid Organization and Enterprise plans, so confirm which MFA controls apply to the plan you buy rather than assuming the identity provider covers them all.
The third gap is provisioning. Twenty lists SCIM provisioning only for Enterprise, so on lower plans, user creation and removal depend on manual work or on the sign-in flow alone. EspoCRM's OIDC support can create users on first login and map identity provider groups to teams, but that does not remove accounts when people leave. User lifecycle for joiners, movers and leavers needs its own written process in every option. Treat EspoCRM API users as a separate population: they sit outside SSO, authenticate with API keys, HMAC or basic authentication, and carry their own role-based permissions. Inventory them, rotate their credentials on a schedule and remove them when the integration or the owner goes away. Ask each vendor for the exact provisioning and deprovisioning behavior in writing before you rely on it.
How to choose and pilot SSO before you commit
This sequence tests each shortlisted CRM's identity path against your own identity provider before any build is funded. It produces a written record of what works on the free tier, what needs a paid plan, and what must be confirmed with the vendor.
Inventory your identity provider and protocols
Your identity team lists the identity provider products in use, the protocols each one supports for applications (SAML, OIDC, LDAP or Active Directory), the group structure that will drive CRM roles, and how users are provisioned and deprovisioned today. The architect records which protocol is the mandatory path and which is a fallback. Done means one signed inventory sheet that the security and CRM leads have both reviewed.
Confirm the free-tier SSO path for each CRM
For each shortlisted CRM, the architect checks which protocol is available in the open-source edition and which requires a paid plan. SuiteCRM 8 offers LDAP (AUTH_TYPE=ldap) and SAML (AUTH_TYPE=saml), EspoCRM documents OpenID Connect and LDAP, and Twenty lists SAML or OIDC SSO on its Organization and Enterprise plans. Ask each vendor in writing to confirm that the mechanism you need is included at the edition you intend to run. Evidence to keep: a dated table of protocol, edition and vendor reference for each product.
Build a non-production pilot with a test tenant
Your platform team deploys each candidate in a staging environment, connected to a test identity provider tenant rather than production directory. They configure the agreed protocol, create a small set of test accounts covering standard users, managers and administrators, and confirm first sign-in behavior, including whether accounts are created on first login where the product supports it. Done means a logged record of successful and failed sign-in attempts for every test account. Keep the staging configuration files in version control.
Test logout and session expiry
Testers sign in, sign out at the CRM, sign out at the identity provider, and wait through the session timeout to see what happens to each open CRM session. The SuiteCRM 8.7.0 and later SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so a sign-out at the identity provider does not end the CRM session. Record each result, and where the behavior is a gap, document a compensating control such as shorter session lifetimes or an access review. Keep the test log with timestamps.
Verify group and role mapping with sample accounts
Using a sample of accounts drawn from each identity group, the CRM administrator confirms that group membership maps to the intended CRM team, role or permission set. Check both the grant and the removal: a user removed from a group should lose access on the next sign-in or sync. Where a product supports group-to-team mapping, such as EspoCRM's OIDC configuration, verify it with real group claims rather than assumptions. Evidence to keep: a matrix of sample users, source groups, expected roles and observed roles, signed off by the business owner.
Review API access as a separate control
SSO for the web interface does not govern API access, so the security engineer reviews API authentication on its own. EspoCRM supports API key, HMAC and basic authentication through dedicated API users, with its documentation describing HMAC as the most secure method and basic authentication as not recommended. Confirm how Twenty's REST and GraphQL tokens are issued and scoped on the edition you plan to run, and how SuiteCRM 8 handles API clients. Done means a written decision for each product on which API method is allowed and who owns the credentials.
Record findings in a written scope before build
The project lead writes up the pilot results for each candidate: the protocol selected, the edition it requires, confirmed logout and session behavior, verified role mapping, and the API decision. Open items are assigned to a named owner with a question to a named vendor or your own environment. DeployOpen plans and implements work under fixed-scope agreements, so the written scope should list deliverables, dependencies and acceptance criteria before any build starts. Done means the approved scope document is signed by the CISO or identity owner and the CRM business owner.
Questions buyers ask before setting up SSO on a self-hosted CRM
What drives the cost of setting up SSO on a self-hosted CRM?
The cost depends mainly on four components: identity provider configuration, hosting, staff time and any paid tier the CRM requires for SSO. Identity provider configuration is the work of creating the SAML or OIDC application, mapping attributes or groups and testing login and logout. Hosting covers the servers and certificates that already run the CRM, plus any added test environment. Staff time is often the largest recurring component, because someone must own the setup after go-live. The paid tier question is the most variable: SuiteCRM (SAML, LDAP) and EspoCRM (OIDC, LDAP) document SSO in their open-source releases, while Twenty's pricing page lists SSO on its Organization and Enterprise plans. Ask any implementation partner for a written quote that separates one-time work from recurring support and licensing.
How long does an SSO pilot take to set up?
The supplied facts do not give a duration for an SSO pilot, so ask for a written estimate that states the assumed timeline. Length is set by how many identity providers and applications are involved, whether the identity provider already has a working test tenant, how many user groups need mapping to CRM roles or teams, and how many login paths (SSO, a local fallback and any LDAP directory) must be tested. Pilots also stretch when logout behavior is unclear. For example, the SuiteCRM SAML reference notes that IdP-initiated logout is not supported in 8.7.0 and later, so logging out at the identity provider does not end the CRM session. Your written scope should list that behavior as a known limit to test and accept or work around.
What does the client need to provide for SSO work?
The work needs three things from the client: administrative access to the identity provider, a test tenant or staging environment for the CRM, and a named owner who can make decisions. Identity provider access lets someone create the application registration, define claims or groups and export the metadata or client details the CRM needs. A test environment protects production users while login flows are checked, and SuiteCRM's migration guidance recommends staging for any change of that kind. The named owner signs off on role mapping, fallback login rules and go-live. Without these, the timeline stretches because approvals and access requests become the critical path. Confirm the exact access model in writing before work starts.
Can our team set up SSO on a self-hosted CRM without outside help?
A team with PHP or MySQL, MariaDB or PostgreSQL administration experience and identity provider admin skills can often configure SSO in-house, but it helps to check three things first. Confirm the CRM release and its supported stack in the vendor documentation, because SuiteCRM 8.10 and EspoCRM 10.0 have different platform matrices. Confirm that the protocol you need (SAML, OIDC or LDAP) is documented for your chosen edition. Then confirm who will own renewals of certificates, the fallback login method and upgrades, since SSO settings can break during a CRM upgrade. An outside partner is most useful when the team lacks one of these skills or when auditors will expect documented evidence of the configuration and testing. DeployOpen works under fixed-scope agreements, so the choice between doing it in-house and hiring help is a scope decision you can price.
Does Twenty's paid SSO or EspoCRM's OIDC change the total cost?
Yes, they change the cost structure, although the answer depends on your user count and required features. Twenty's pricing page lists Pro at 9 US dollars per user per month and Organization at 19 dollars per user per month, with SAML or OIDC SSO included in Organization, so choosing Twenty for SSO means budgeting per-seat licensing that recurs. Enterprise adds SCIM provisioning and an SLA, but the pricing page lists it from 50,000 dollars a year. EspoCRM's OIDC support is documented as part of its open-source edition since version 7.3, so SSO itself does not require a paid tier, though its own two-factor authentication is not compatible with OIDC. Compare the recurring seat cost against one-time configuration work and ask each vendor and partner for a written breakdown.
What should we check on the identity provider before starting?
Check the identity provider's protocol support, the attributes it can send and how it handles logout, because these decide most of the CRM configuration. Confirm whether the provider can issue SAML assertions or OIDC tokens, which claims or groups it will send, and whether a test application can be created without affecting production users. Then confirm the CRM's logout behavior and whether LDAP is needed for directory lookups. For example, SuiteCRM 8 supports LDAP through the AUTH_TYPE setting with the value ldap and SAML through the value saml, so the chosen value must match the protocol you can deliver. Write these answers into the scope so both sides test the same flow.
Does SSO on a self-hosted CRM replace the need for a fallback login?
No. Every SSO design should keep a documented fallback login so administrators can recover access if the identity provider is unavailable or misconfigured. EspoCRM's OIDC documentation describes a fallback login method, and SuiteCRM's configuration references should be reviewed for how local accounts behave when SAML or LDAP is enabled. Decide in writing who holds fallback credentials, where they are stored and how they are tested. This is a security decision as much as an operational one, and a review by your security team should cover it before go-live.
How DeployOpen scopes SSO selection and integration
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a CRM with single sign-on, we start from your identity provider, your directory and your licensing position, then agree a fixed scope in writing before any work begins.
How we scope
- Confirm which identity provider and protocol (SAML, OIDC or LDAP) your environment already runs.
- Record which CRM edition, paid tier or extension the SSO requirement depends on before choosing a platform.
- Agree deliverables, test cases and timelines in writing, with a quote that follows directly from that written scope.
How we build
- Configure the chosen CRM's SSO connection in a non-production environment that mirrors your production setup.
- Test sign-in, first-login user creation, group or team mapping and logout behavior against your identity provider.
- Document fallback login paths and how local admin access is kept separate from single sign-on.
How we hand over
- Deliver configuration records, runbooks and a test report covering each identity flow that was agreed in scope.
- Walk your identity, security and CRM administrators through the setup so they can operate and change it.
- Record the upgrade and rollback steps for the SSO settings so they survive future CRM releases.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately.
- Re-test SSO flows when the CRM or identity provider is upgraded, and report what changed.
- Confirm with the vendor, and with your own environment, any SSO feature not covered in the written scope.
