EspoCRM SSO and identity integration guide

Why EspoCRM SSO is more than a login setting

Single sign-on for EspoCRM means staff authenticate against the corporate identity provider, and EspoCRM accepts that sign-in through OpenID Connect. EspoCRM has supported OIDC sign-in since version 7.3, with optional user creation on first login, mapping of identity provider groups to EspoCRM teams, backchannel logout and a fallback login method. LDAP and Active Directory are also documented as alternatives, so the first decision is which protocol matches how your identity provider already issues users and groups. Entra ID, Keycloak and other OIDC providers all need the same set of decisions to be made, even though their admin consoles differ. The harder part is what happens after the login succeeds. A user who signs in through the identity provider still needs the right EspoCRM user record, the right teams and the right role. If user creation on first login is switched on, the account is created with whatever defaults you configured, so you need to decide in advance which teams and roles a new account receives, and which group claims map to which teams. Group to team mapping determines record visibility for sales and service staff, so an incorrect mapping is a data access problem, not a cosmetic one. Confirm the claim names your provider sends, test with a sample of real group memberships, and review who holds administrator rights before go-live. The fallback login path needs a deliberate design. Administrators need a way into EspoCRM if the identity provider is unavailable or misconfigured, and that path must not become a second weak door. Keep the fallback limited to named administrator accounts, avoid using admin accounts for daily work, and decide who can use it and how that use is logged. EspoCRM's own two-factor authentication is not compatible with OIDC sign-in, so the identity provider must enforce multi-factor authentication for OIDC users. Confirm how the fallback account is protected in its place, because the EspoCRM security guidance also recommends requiring 2FA, and that requirement cannot be met by EspoCRM's native setting on the OIDC path. Finally, test logout and deprovisioning as carefully as login. Backchannel logout is meant to end EspoCRM sessions when the identity provider signs a user out, but you should verify that behavior with your provider's actual session and token settings rather than assume it. Disabling a user in the identity provider should also stop access to EspoCRM, and the test plan should cover a leaver, a role change and a user removed from a mapped group. Document the expected result for each case, run the tests in a non-production instance, and assign an owner for re-running them after upgrades or provider changes.

What an EspoCRM SSO setup touches

An EspoCRM SSO setup spans three places: the OpenID Connect settings inside EspoCRM, the client registration on the identity provider, and the fallback and directory choices that decide who can still sign in. Each card below is a setting or decision that has to agree with the others, and the exact field names and screens should be confirmed against the EspoCRM OIDC documentation for the version you run.

OIDC authentication settings

The OpenID Connect section in the EspoCRM administration area holds the issuer, client identifier, client secret and the scopes EspoCRM requests at sign-in. These values must match the client registered at the identity provider exactly, including the issuer URL format. Confirm the field names and the screen layout against the OIDC documentation for your EspoCRM version before you write the configuration down as a runbook.

Identity provider client registration

The client on Entra ID, Keycloak or another provider defines the redirect URI that EspoCRM will accept, the scopes it may request, and whether group or role claims appear in the token. A redirect URI that differs from the public EspoCRM address by a trailing path or scheme will fail at sign-in. Record who owns this registration, because the client secret and redirect URI must change together during any hostname move.

User creation on first login

EspoCRM can create a user record the first time a person signs in through OIDC, or it can require an administrator to create the user beforehand. The choice decides whether a directory account gains CRM access automatically and which default role and profile it receives. Agree the rule with the security owner, and check how deprovisioned staff are removed, since an account created at first login does not disappear on its own.

Group to team mapping

EspoCRM can map identity provider groups to its own teams so that record visibility follows the sales or service structure. The group claim must be emitted by the provider, and the group names must match what EspoCRM expects. Test with a small set of accounts from each team, because a missing or misspelled group leaves users in no team and can hide records they need.

Backchannel logout endpoint

The backchannel logout endpoint lets the identity provider notify EspoCRM when a session ends, so that a disabled user loses CRM access without waiting for the token to expire. Confirm that your provider sends logout tokens to the URL EspoCRM exposes and that the provider's own logout is wired to the same session model. Test with a disabled test account, not only with a normal sign-out.

Fallback login method

A fallback login lets administrators sign in with a local EspoCRM password when the identity provider is unavailable. It is a deliberate exception to central control, so decide who may use it, store its credentials under controlled access, and confirm how it interacts with the password policy and admin account hygiene in the security documentation. EspoCRM's own two-factor authentication is not compatible with OIDC, so the stronger control for this path must come from the provider.

LDAP and Active Directory alternative

EspoCRM also documents LDAP authentication, including Active Directory and OpenLDAP, as an alternative to OIDC. Choose one primary method for the instance so that users are not split across two sign-in paths with different rules. Confirm the bind account, the search base, and how group membership is read in your directory, since those settings are separate from the OIDC configuration.

Which identity pattern fits your EspoCRM environment

This table compares the four identity patterns we see for EspoCRM: direct OIDC with a cloud identity provider, OIDC through a broker, LDAP or Active Directory, and external portal access. Read each row as a decision: when the pattern fits and what it asks your team to run afterward. The main takeaway is that the identity provider you already operate usually decides the pattern, while the number of user populations decides whether you need a second one.

Pattern	When it fits	Operational cost	Who owns it
Direct OIDC with a cloud identity provider such as Entra ID	Users are already in a cloud directory, and the provider can issue OIDC clients for EspoCRM. Suited to a single internal user population.	Client registration, redirect URI and claim configuration, and group claim setup for team mapping. Confirm group claim limits with the provider before design.	Identity team owns the app registration; CRM team owns team mapping and fallback login.
OIDC through a broker such as Keycloak that federates to Entra ID	You need several applications to share one login, or you need to add identity sources, protocol mappers or session rules without changing EspoCRM.	An extra service to host, patch, back up and monitor, plus federation mappers that must be tested after each change. Backchannel logout depends on the broker session model.	Usually the platform or security team owns the broker; the CRM team owns the EspoCRM client and mappings.
LDAP or Active Directory where the directory is on premises and OIDC is not available	Users sign in against an on-premises directory, and the network path from EspoCRM to the domain controllers is permitted by your security policy.	Directory connectivity, service account management, TLS for the LDAP connection and group filter tuning. Sessions remain governed by EspoCRM, so logout and token lifetime need separate review.	Directory team owns the service account and network path; CRM team owns the authentication settings.
Portal or external users with OIDC	Customers or partners need portal access. Decide whether they should authenticate through your workforce provider, a separate external identity source, or a local EspoCRM account with its own controls.	Separate user population, onboarding and offboarding process, and password or 2FA rules. Keep external accounts apart from internal team mapping so they do not inherit internal groups.	Business owner approves access; identity team owns the external source if one is used.

How to build EspoCRM SSO step by step

This sequence takes an EspoCRM instance from confirming the OpenID Connect prerequisites to a tested single sign-on setup with mapped teams, working logout and a documented admin fallback. Each step closes with a check you can run before moving on, so the pilot starts from a known-good configuration.

Confirm the EspoCRM version and OIDC prerequisites
The platform team confirms that the instance runs EspoCRM 7.3 or later, since OpenID Connect sign-in is available from that version onward. They also check the server stack against the current server configuration docs, including PHP, the database engine and the web server, and confirm that cron is running for background jobs. Record the exact version and stack in the build log. The step is done when the version check passes on the target instance and the staging copy, and both report the same release.
Register EspoCRM with the identity provider
The identity administrator creates an OIDC client for EspoCRM in the chosen provider, such as Entra ID or Keycloak, and records the client ID, the client secret handling method and the issuer URL. Redirect URIs must match the EspoCRM callback address for each environment exactly, including the staging and production hostnames. Ask the provider which logout and post-logout redirect fields it supports, since you will need them for backchannel logout later. The step is done when a test sign-in request from the provider's own tooling reaches the EspoCRM host and returns to it without an error.
Choose and test the team mapping attribute
Decide which token claim or group attribute will drive team membership, such as a group ID or a department claim. Keep the choice small and stable, because EspoCRM teams will depend on it. Create a sample account in the identity provider, assign it to one test group and inspect the token or userinfo response to confirm the claim arrives with the expected name and value. Note any multi-valued or nested group formats. The step is done when the sample account's claim is captured in the build log with the exact field path and value.
Configure OIDC settings and first-login user creation
The EspoCRM administrator enters the provider details in the OIDC authentication settings, using the issuer, client ID, secret and scopes from the earlier steps. Enable user creation on first login only if the business has agreed who is allowed to sign in, and set the default user type and status for new accounts. Disable EspoCRM's own two-factor authentication for OIDC users, since it is not compatible with OIDC, and make sure the identity provider enforces its own second factor. The step is done when a sample user signs in through the provider, a new EspoCRM user record appears with the expected profile, and no EspoCRM 2FA prompt appears.
Map identity groups to EspoCRM teams
Using the claim chosen in the third step, the administrator maps each identity provider group to one EspoCRM team and sets a default team for users who match no group. Document each mapping in a table that names the provider group, the EspoCRM team and the owner who approved it. Test edge cases, including a user in two groups, a user in none and a user removed from a group after sign-in. Confirm team membership refreshes at the next sign-in as the configuration describes. The step is done when every test account lands in the expected team and the mapping table has been approved by the business owner.
Configure and verify backchannel logout
The integration engineer enables backchannel logout in the EspoCRM OIDC settings and configures the matching logout endpoint on the identity provider side. Confirm the provider can send the logout message to the EspoCRM server and that the server accepts it from the provider's network path, including any proxy or firewall rules between them. Test by signing a user in on two browsers, ending the session in the provider and checking that the EspoCRM session closes. Record the test result and any gaps, such as sessions that remain open on mobile clients. The step is done when the EspoCRM session ends within the test window and the result is documented.
Set up fallback login and restrict admin accounts
Name the administrators who need a fallback path for when the identity provider is unavailable, and create a separate local login for each of them with a strong, unique password stored in the approved vault. Document the fallback procedure, who may invoke it, and how access is revoked afterward. Confirm that admin accounts are not used for daily work and that password recovery is disabled for admin users, following the EspoCRM security guidance. Restrict admin access by IP address where the network allows it. The step is done when a named admin can use the fallback login in a test, password recovery is confirmed off for admins, and the runbook is signed off.
Run the pilot with a small group before cutover
Select a small group of real users from one team, agree on a support contact and a rollback path with the business owner, and enable OIDC sign-in for that group only. Watch sign-in success, team assignment, logout behavior and any user complaints for the pilot period agreed in advance. Collect issues into a list, fix them in the configuration, and retest the affected step before widening access. Keep the fallback login in place during the pilot. The step is done when the pilot group has signed in without blocking issues, the open items are closed or accepted in writing, and the business owner approves the wider rollout.

What drives the effort of an EspoCRM SSO project

This table lists the factors that most change the amount of work in an EspoCRM single sign-on project, with a note on how to keep each one manageable. Read each row as a question to answer before scoping, since the answers determine whether the work stays small or grows across identity, EspoCRM configuration and security review.

Driver	Why it changes effort	How to keep it down
Identity providers and tenants	Each provider or tenant needs its own OIDC client, redirect settings, claim checks and test sign-ins. Multiple tenants also multiply the group mapping rules.	Confirm early which identity provider and tenant will be used for staff and whether any second source of users is truly needed.
Group to team model	Mapping directory groups to EspoCRM teams is simple for a few teams and becomes a design exercise when groups are nested, overlap or do not match how sales and service teams work.	Agree the group naming scheme and a one-to-one or simple mapping before configuration starts, and document exceptions.
Teams and roles that follow directory changes	Every joiner, mover and leaver change in the directory must produce the right team and role in EspoCRM. Manual corrections add recurring work and audit questions.	Define which attributes drive team and role assignment, test a move between teams, and confirm who owns the mapping after go-live.
Keycloak broker between EspoCRM and Entra ID	A broker adds a second identity layer to configure, monitor and patch. Claim and group translation happens in two places, which increases troubleshooting time.	Decide whether the broker is needed for federation, protocol translation or policy. If it is not needed, connect EspoCRM directly and record the reason.
LDAP or Active Directory instead of OIDC	LDAP authentication changes how credentials and group lookups work, and it can complicate remote and cloud-hosted access. It also needs network paths from EspoCRM to directory servers.	Confirm the directory platform, network reachability and service account rules first. Choose OIDC where the identity provider supports it and the security team agrees.
External and portal users	Portal or customer logins often need a different identity source, separate team and role design, and different self-service rules. Mixing them with staff accounts raises the test load.	Decide whether external users are in scope for this phase. If they are, scope them as a separate group with their own role tests.
Backchannel logout across applications	Testing that a logout in the identity provider ends sessions in EspoCRM and other connected applications requires each application to be set up and checked together.	List every application that must receive logout events and test them as one scenario. Limit the first release to the applications that truly need it.
Change control and evidence requirements	Security teams often ask for change tickets, test records, configuration exports and access review evidence. Each artifact adds preparation time before and after each change.	Agree the evidence list at the start, including who approves changes and where records are stored. Use one template for each change.
Administrator access and fallback login	Admin accounts must keep a working fallback login if the identity provider fails. Decisions on who holds admin roles, and how fallback access is recorded, affect both design and review.	Limit administrator roles to a small named group, keep a documented fallback path tested before go-live, and avoid using admin accounts for daily work.

How SSO differs across deployment models

The installation script deploys a Docker-based stack with Nginx and MariaDB on Ubuntu, Debian or Linux Mint. On one node, the application, the reverse proxy and the callback all sit behind one public hostname, so the OIDC redirect URI is simple to define. The main risks are a hostname mismatch and a certificate that does not match the address the identity provider sees.

Hostname and redirect URI: Register the exact public hostname, including the HTTPS scheme, with the identity provider before testing sign-in.
Certificates: If the optional Let's Encrypt certificate is enabled, confirm the hostname resolves publicly so the issuer and callback use valid HTTPS.
Backups and restores: The command.sh utility handles backups, restores and upgrades. Test that a restored instance still signs users in against the same provider settings.
Scheduled jobs: EspoCRM needs cron or a scheduled task for background jobs. Confirm it runs after installation, because a stopped job can look like a sign-in fault.
2FA: EspoCRM's own two-factor authentication is not compatible with OIDC, so decide where second-factor checks happen in your identity provider.

Before handing sign-in to users, check the hostname, certificate and redirect URI together in one test pass.

How to lock down EspoCRM sign-in

The controls below narrow what an attacker can reach after sign-in and cover the gaps that single sign-on creates. Some sit inside EspoCRM, some sit with the identity provider, and some sit in how credentials are stored and how integrations authenticate. Review them together with your identity team before go-live, because a control that looks complete in one system can be bypassed through another.

Named fallback administrator account

Keep one named administrator account that exists only for SSO failures, such as an identity provider outage or a misconfigured OIDC setting. Give it a strong, unique credential, store it in a sealed location, and test that it signs in on a schedule. Restrict password recovery for admin accounts so this account cannot be reset by email, and confirm the setting after each upgrade. Daily administration should happen in a separate account.

Limit auth token lifetime

Set the auth token lifetime to the shortest value your users can tolerate, so a stolen browser session or token expires soon after use. Agree the value with your security team and the identity provider's session policy, because a long EspoCRM token can outlive a session the provider has already ended. Check how users are signed out when they leave, and confirm the exact setting name and default in the EspoCRM security documentation for your version.

Restrict admin access by IP address

Limit the administration area to known network ranges, such as a corporate VPN egress or a privileged access jump host, so administrative sign-in is not possible from arbitrary internet locations. Confirm how EspoCRM reads client addresses behind a reverse proxy or load balancer, because a misread address can either lock out administrators or allow the restriction to be bypassed. Test from an allowed network and a blocked network before go-live, and document who can change the allowed list.

Enforce MFA at the identity provider

EspoCRM's own two-factor authentication is not compatible with OIDC sign-in, so multifactor authentication for SSO users must come from the identity provider. Define the policy there: which users, which applications, which factors, and whether it applies to every sign-in path. Check the fallback administrator path separately, since it uses a local password and skips the provider's policy unless you add compensating controls. Ask the provider's administrators to confirm the policy in writing and test it with a non-admin account.

Secrets and TLS for identity links

Hold the OIDC client secret and the LDAP bind account password in a secrets store or another mechanism your platform controls, and keep them out of configuration files and source control. Limit who can read them, and rotate them after staff changes. Register the exact HTTPS redirect URI with the provider, and confirm the LDAP connection uses encryption. Verify certificate validation on every hop, including back-channel calls to the provider.

API keys or HMAC for integrations

Integrations that run without a person should not sign in through OIDC or LDAP. Create dedicated API users with narrow role permissions and use HMAC authentication, which the EspoCRM documentation describes as the most secure of the supported methods. Avoid basic authentication, which the documentation does not recommend. Store each integration's credentials in the same secrets store as other secrets, rotate them on a schedule, and confirm the API user cannot reach administrative screens.

How to test EspoCRM SSO and confirm it fails safely

Test the sign-in path before any user depends on it, and start with the cases that could lock people out or let the wrong person in. The first test is a first-time user. Use a test account in a test group in your identity provider, sign in through the OpenID Connect flow, and confirm that EspoCRM creates the user only if user creation on first login is enabled in your configuration. Then check that the user receives exactly the teams that the group mapping specifies. Repeat the test with a user whose group has no mapping and record what EspoCRM does. Your design decides whether that user is denied or created without teams, so write the expected result down before you test.

The second and third tests cover changes in the directory. Move the test user from one mapped group to another, sign in again, and confirm that team membership in EspoCRM matches the new group. Check that the old team is removed as well as the new one added, because a team that lingers is an access problem. For a disabled account, test two routes separately. In the session expiry test, confirm the user is blocked once the session ends and cannot resume it. In the backchannel logout test, confirm that the identity provider notifies EspoCRM and that open sessions end. Backchannel logout depends on the provider sending the message and on your EspoCRM version, so confirm the expected behavior in the OIDC documentation and time how long access persists in each case.

Next, test the failure of the identity provider itself. In a test environment, stop the provider or block its route, then confirm that the fallback login method still lets a named administrator sign in. This break-glass account should not be used for daily work, should hold a strong password under your own custody controls, and should fall under the same controls your security team applies to other privileged accounts. While you are testing admin accounts, attempt password recovery on one and confirm it is blocked, as the EspoCRM security guidance recommends. Finally, let an access token expire and confirm that the user must reauthenticate before continuing.

Review the EspoCRM logs after each test run and look for failed sign-in attempts that match your test timestamps. Confirm that every test event appears in the logs and that no failure is left unexplained. Keep an evidence package for the security or audit team. It should include the test ID, date, tester, EspoCRM version, identity provider configuration with secrets removed, the expected and actual result for each case, screenshots or log extracts, and the identity provider event records for the same sessions. Give each test a pass, fail or open status. If a test does not behave as the documentation describes, do not accept a workaround silently. Ask the vendor or the open-source project to confirm whether the behavior is a defect, a configuration issue or a documentation gap, and record the answer alongside the finding.

What to monitor, back up and document after go-live

Once single sign-on is live, the risk shifts from building the integration to keeping it working. The items below cover what to watch, what to test on a schedule, and what to record so that an identity change, certificate expiry or EspoCRM upgrade does not lock users out or quietly break group-based access.

Monitor failed sign-ins and outages

Track failed OIDC sign-ins in EspoCRM logs and watch for patterns, such as a spike after a provider change or repeated callback errors. Separately, monitor the identity provider's own availability, because an outage there stops every SSO user at once. Agree who receives these alerts and what response is expected before go-live, not after the first incident.

Review group to team mappings

Group to team mapping is only as current as the directory behind it. When teams are renamed, groups are split or merged, or people change departments, review the mapping table against the identity provider and EspoCRM teams. Stale mappings can give users access to records they should not see, or remove access from people who still need it.

Track certificate and secret rotation

Record the expiry dates of signing certificates, TLS certificates and the OIDC client secret, and set reminders well before each one lapses. Confirm with your identity provider how rotation is done and whether the old secret stays valid during the switch. An expired certificate or secret typically fails every login at once, so treat these dates as operational items, not annual housekeeping.

Test the fallback login regularly

EspoCRM's fallback login method is what lets administrators reach the instance when the provider is down or misconfigured. Test it on a fixed schedule, using a named admin account, and confirm that the account still has a working credential, is not tied to a personal mailbox, and is not blocked by password recovery settings. Record each test result and the date it was run.

Back up configuration and database

Take a backup of the EspoCRM configuration and database before every change to the OIDC settings, the mapping table or the identity provider integration. Confirm that the backup can be restored, not only created. The EspoCRM installation script includes a command.sh utility for backups and restores, which you can use as a starting point if your deployment is based on it.

Re-test SSO after upgrades

Check the OIDC settings against each EspoCRM upgrade before users return to the system. Upgrades can change configuration expectations, and custom code or extensions may interact with authentication. Keep a short test script covering sign-in, first-login user creation, group mapping, logout and the fallback login, and run it on a staging copy before production. Confirm the current upgrade path with EspoCRM's documentation.

Confirm cron runs background jobs

Several EspoCRM background jobs depend on cron, and the server configuration documentation lists cron or a scheduled task as required for them. Verify that the cron entry exists, runs as the correct user and is still running after server maintenance. Jobs that silently stop can affect processes that rely on them, so include cron health in your monitoring checks.

Document mapping, fallback and owners

Keep a current record of the group to team mapping table, the fallback login procedure and the named owner of each identity component, including the identity provider application, the client secret, the certificate, the EspoCRM instance and the directory groups. Review this record at each upgrade and each directory change, so that the person on call can act without reconstructing the setup.

Questions buyers ask about EspoCRM SSO

How much does EspoCRM SSO integration cost?

The cost depends on the written scope, not on a list price. Who is paid for what: the identity provider work (Entra ID, Keycloak or another provider), the EspoCRM OIDC configuration, group to team mapping, testing, and handover documentation. One-time versus recurring: the integration itself is one-time work, while identity provider licensing, hosting, and any later changes or upgrade testing recur. What drives cost up: the number of identity providers, the complexity of group design, the need for backchannel logout, OIDC for portals, and the number of environments to test. A quote should list each of these items, the environments covered, the test cases, who owns the fallback admin login, and what is excluded. DeployOpen does not publish prices, and a quote follows from the written scope.

How long does EspoCRM SSO take to implement?

Duration depends on how much of the identity design already exists. Teams that already run a working OIDC provider with defined groups usually need less time than teams that must design groups, clean up accounts, and agree on access rules first. Main drivers: whether the identity provider application registration is available, how many EspoCRM roles and teams must map to groups, whether user creation on first login is required, whether a separate test instance exists, and how many approval cycles the security team requires. Ask for the schedule as a set of milestones tied to these inputs, and confirm which dependencies sit with your identity team. Any timeline in a proposal should follow from the agreed scope and be confirmed in writing before work starts.

Can our internal team set up EspoCRM SSO without a partner?

Yes, a capable internal team can do it, provided it has three skill sets. Identity provider administration: creating the application registration, configuring redirect URIs, issuing client credentials, defining groups, and managing claims. EspoCRM administration: configuring the OIDC settings in the administration area, setting the fallback login, and mapping groups to teams and roles. Testing: verifying sign-in, first-login user creation, group changes, deprovisioning, and logout behavior across browsers. Most delays come from one of these areas being thin, usually testing or the fallback admin path. Confirm named owners for each area before starting, and check the current EspoCRM OIDC documentation for your release.

Does EspoCRM SSO work with Entra ID and Keycloak?

EspoCRM supports OpenID Connect sign-in, so providers that implement OIDC can be used, and Entra ID and Keycloak are common choices. However, the exact provider configuration, including the issuer URL format, scopes, claim names for groups, and logout endpoints, must be confirmed against the provider version you run and the EspoCRM release you deploy. Confirm before purchase: which claim carries group membership, whether group names or identifiers are sent, how your tenant limits group claims, and whether backchannel logout is supported in your setup. A short proof of concept in a test instance is the most reliable way to confirm these details.

Can EspoCRM two-factor authentication be used together with SSO?

No. EspoCRM's own two-factor authentication is not compatible with OIDC sign-in, so enforcing 2FA inside EspoCRM does not apply to SSO users. The identity provider must enforce the second factor, for example through conditional access policies, multi-factor settings in the provider, or a step-up rule for EspoCRM applications. Confirm that every access path, including the fallback login for administrators, has its own strong authentication requirement. Review the EspoCRM security documentation for the controls that still apply inside the application, such as token lifetime and IP restrictions.

Is LDAP or Active Directory a substitute for EspoCRM SSO?

LDAP and Active Directory are a supported alternative, not a direct substitute. EspoCRM documents LDAP authentication, including Active Directory and OpenLDAP, so it fits organizations whose accounts live in a directory and whose users sign in with directory credentials. OIDC fits better when you need federation with cloud applications, conditional access, or sign-in for external users. Decision points: where the authoritative identity source sits, whether you need modern multi-factor policy, how group membership is maintained, and who operates the directory connection and its certificates. Many teams evaluate both against their identity architecture before choosing one.

What does the SSO work need from our side?

The work depends on access from your identity team, so agree these inputs before the project starts. Directory and provider access: an administrator role or delegated rights to create the application registration and read group membership. Group design: the groups that will map to EspoCRM teams and roles, who approves membership changes, and how leavers are removed. Named administrators: at least two people who will own the EspoCRM OIDC settings and the fallback admin login, plus a contact for the identity provider. Environments and test accounts: a test instance and representative test users. Missing inputs are the most common cause of schedule slips, so list them in the statement of work with owners and due dates.

How DeployOpen scopes, builds and hands over EspoCRM SSO

DeployOpen plans and implements EspoCRM SSO inside your own infrastructure, so the identity provider, the CRM and the login policy are configured to match how your teams sign in. Each engagement follows a written, fixed scope, with ongoing support available as a retainer.

How we scope

Inventory the identity provider, its client registration and which EspoCRM users, groups and portals need single sign-on.
Agree in writing how identity provider groups map to EspoCRM teams and whether first-login user creation is allowed.
Define the fallback login method for administrators and confirm how EspoCRM's own two-factor authentication will be replaced.

How we build

Configure the OpenID Connect client in EspoCRM and the matching application in your provider, then test redirect URIs in a non-production instance.
Build and test group-to-team mapping, backchannel logout and portal sign-in against named test accounts for each role.
Where Active Directory or LDAP is the chosen alternative, verify bind accounts, search scope and attribute mapping before any cutover.

How we hand over

Deliver a written configuration record covering provider settings, mappings, fallback login procedure and the test results for each role.
Walk through the runbook with your identity and CRM administrators, including how to add a group mapping and rotate client secrets.
Document the verification steps you can repeat after EspoCRM or provider upgrades, so access changes stay controlled.

How we support

Review sign-in logs, mapping drift and provider changes on a schedule agreed in the written scope or a support retainer.
Retest single sign-on after each EspoCRM upgrade and each change to the identity provider's applications or claims.
Confirm with your provider and your own environment which features, such as backchannel logout, your version supports before planning.