CRM single sign-on (CRM SSO) uses an identity provider (IdP) to authenticate users, so employees can sign in to the CRM through the same identity system they use for other workplace tools. Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) handle authentication, while System for Cross-domain Identity Management (SCIM) handles a separate job: provisioning and deprovisioning user accounts. Keeping those roles distinct helps teams reduce lockout and access-governance risk during rollout.
Before going further, here are the key terms:
- SAML: An XML-based standard that lets an IdP send authentication assertions and attributes to an application.
- OIDC: An identity layer built on OAuth 2.0 that lets an application verify a user’s identity and receive identity claims.
- SCIM: A standard for automating user-account provisioning, updates, and deprovisioning between systems.
- Multi-factor authentication (MFA): Authentication that requires multiple verification factors. When an IdP enforces MFA, that check can be part of the SSO sign-in flow.
- IdP: The system that authenticates the user and sends trusted assertions or tokens to the CRM. Common examples include Microsoft Entra ID, Okta, OneLogin, and Google.
- Provisioning and deprovisioning: Creating or updating a user’s account and access when they join or change roles, then disabling or removing access when they leave.
SSO centralizes authentication, which is how users prove who they are. SCIM automates account lifecycle management, which is how accounts are created, updated, and retired. SSO and SCIM often work together, but they solve different problems.
Table of Contents
- What is CRM SSO? Plus, Why CRM SSO Matters
- How CRM SSO Works With SAML, OIDC, and Your IdP
- CRM SSO Benefits and Risks to Weigh
- CRM SSO Setup Steps You Can Follow Today
- How HubSpot Supports SSO and SCIM
- Frequently Asked Questions About CRM SSO
- Launching a Connected CRM With SSO
What is CRM SSO? Plus, Why CRM SSO Matters
CRM SSO means employees access the CRM through a central identity provider instead of relying on a separate CRM password. The IdP authenticates the user, sends a trusted assertion or token, and the CRM grants access based on mapped roles, groups, and policies.
For employees, CRM SSO can mean fewer credentials and sign-in steps. For IT and security teams, CRM SSO centralizes authentication policy and makes sign-in activity easier to audit. When you also configure SCIM, the IdP can automate user creation, updates, and deactivation in the CRM. Those access controls complement the broader benefits of a CRM system by reducing authentication friction while giving administrators more centralized control.
How CRM SSO Works With SAML, OIDC, and Your IdP
At the authentication layer of a CRM integration, SAML and OIDC solve the same core problem: They let an application rely on an identity provider to authenticate a user. They use different message formats and flows, while SCIM sits outside the sign-in flow and manages user accounts.
SAML vs. OIDC vs. SCIM
SAML 2.0 uses XML-based assertions. In a typical web SSO flow, the IdP authenticates the user and sends an assertion to the service provider, which validates it and applies its own access rules.
OIDC is an identity layer on OAuth 2.0. It lets an application verify the user’s identity and receive user claims. OIDC is commonly used for modern web and mobile authentication flows.
SCIM does not authenticate users. It manages account lifecycle data through provisioning APIs. A product can support SCIM independently of the authentication protocol it uses, though some products require SSO to be enabled before you can configure SCIM.
CRM SSO Benefits and Risks to Weigh
CRM SSO can reduce sign-in friction for users and centralize more authentication controls for administrators. Still, CRM SSO also creates a dependency on the identity provider that teams need to plan around.
CRM SSO Benefits
For users, the clearest benefit is fewer CRM-specific credentials and sign-in prompts. Removing that access friction can support CRM adoption.
For administrators, SSO centralizes identity-provider controls such as MFA and sign-in policy, making access governance easier to coordinate with a broader CRM strategy. The CRM can still have its own session, authorization, and permission settings, so SSO does not eliminate application-level controls. When SCIM is configured, it can also automate account provisioning and deactivation, reducing manual offboarding work.
CRM SSO Risk
SSO creates a dependency on the identity provider. An IdP outage or misconfiguration can block users from the CRM and other connected applications. Pilot testing reduces that risk by exposing configuration mismatches before SSO is required for the full user population.
Plan a fallback path before go-live. Depending on the CRM, that might mean exempting an emergency administrator account from SSO, documenting how to turn off the SSO requirement, or maintaining another vendor-supported recovery method. Test the fallback before an outage.
CRM SSO Setup Steps You Can Follow Today
Setting up CRM SSO follows a predictable sequence: Prepare your IdP and CRM, test the connection, then enforce access policies once the integration works as expected.
1. Prepare your IdP and CRM.
Confirm that your CRM edition supports the SSO protocol you plan to use and review its administrator, domain, and user-management prerequisites. Define the CRM’s roles or permission model, then map IdP groups or attributes to the access each user type needs. If you also plan to use SCIM, review the CRM’s provisioning prerequisites before building those mappings.
2. Exchange metadata and test.
For SAML, configure the service provider and IdP with each other’s required values. Common service-provider values include an entity ID (audience) and an Assertion Consumer Service (ACS) URL. Common IdP values include an issuer or identifier, SSO URL, and signing certificate. Exact fields vary by product, so follow the CRM and IdP documentation rather than assuming both sides use the same metadata format.
Test with a small pilot group before requiring SSO for everyone. A pilot can surface certificate, URL, claim, and role-mapping problems while limiting the affected population.
3. Map roles and enforce MFA.
With authentication working, map IdP groups, roles, or claims to the CRM’s permissions and test each user type. SCIM role-to-permission behavior is product-specific; if the CRM requires exact names or case matching, mirror those values exactly.
Enforce MFA through the IdP per your organization’s security policy, and confirm the MFA step works in the SSO flow. Also test deprovisioning so removing or disabling a user at the IdP produces the intended access change in the CRM.
How HubSpot Supports SSO and SCIM
HubSpot’s SSO setup uses SAML 2.0 and requires Super Admin permissions to configure or edit. HubSpot provides setup guidance for Okta, OneLogin, Microsoft Entra ID (formerly Azure AD), and Google. During configuration, HubSpot provides service-provider values such as the Audience URI and sign-on/ACS values for the IdP, and the administrator supplies the IdP’s issuer, SSO URL, certificate, or federation metadata back to HubSpot.
HubSpot account SSO is currently available with Professional and Enterprise editions of Marketing Hub, Sales Hub, Service Hub, Data Hub, Content Hub, HubSpot Smart CRM, and Revenue Hub. After you configure SSO, HubSpot can require it for users. HubSpot recommends keeping at least one Super Admin exempt from that requirement so that, if the IdP is unavailable, the administrator can still sign in and temporarily turn off required SSO.
For SCIM provisioning, HubSpot requires SSO to be enabled before you can configure SCIM. The custom SCIM feature requires a Professional or Enterprise account. HubSpot also provides dedicated provisioning paths for Google and Okta. Their current documentation lists Marketing Hub, Sales Hub, Service Hub, Content Hub, and Revenue Hub Professional and Enterprise. Other IdPs, including Microsoft Entra ID, PingFederate, OneLogin, and JumpCloud, can use HubSpot’s custom SCIM developer path.
A few HubSpot-specific caveats are worth planning around:
- Domain verification: SCIM setup requires DNS verification with a TXT record. DNS changes can take up to 48 hours to propagate.
- Permission-set matching: When permission-set role sync is enabled, the IdP role name must exactly match the HubSpot permission-set name, including spaces and capitalization.
- Seat assignment: Seat behavior varies by SCIM path and pricing model. In HubSpot’s custom SCIM developer flow, seats-based accounts must update the user’s seat in HubSpot before assigning permissions through the IdP. With Okta on the seats-based pricing model, HubSpot automatically assigns the best available seat that supports the synced permission set. Google has its own seat and permission-set requirements, so follow the provider-specific setup documentation.
- Deprovisioning direction: Deprovisioning behavior varies by SCIM path. With HubSpot’s custom SCIM integration and Okta, removing HubSpot access or deactivating the user in the IdP deactivates that user in HubSpot. With Google, removing HubSpot access or deactivating the user in Google deletes the user in HubSpot. Deleting a user in HubSpot does not delete the user in the IdP.
Frequently Asked Questions About CRM SSO
Does SSO replace MFA?
No. SSO and MFA do different things. SSO centralizes authentication, while MFA requires additional verification factors. If the IdP enforces MFA, that check can be part of the SSO flow. In HubSpot, users who are required to sign in with SSO are not also required to set up HubSpot two-factor authentication (2FA).
What is the difference between SAML and OIDC?
Both can support federated authentication, but they use different standards and flows. SAML 2.0 uses XML-based assertions, while OIDC is an identity layer on OAuth 2.0 that uses claims to share user information. HubSpot’s documented account SSO flow uses SAML, not OIDC.
Can we use SSO for customer or partner portals?
It depends on the CRM and on who needs access. Employee and administrator account SSO and portal or private-content SSO can be separate configurations. In HubSpot, private-content SSO is designed for internal visitors who have access to the HubSpot application in your identity provider; it is not a general authentication method for external customers or partners. The feature is available with Content Hub Professional and Enterprise and Service Hub Professional and Enterprise. Content Hub can protect blogs, landing pages, and website pages, while Service Hub can protect knowledge base articles and customer portals.
What happens during an IdP outage?
Use the fallback path you tested before go-live. In HubSpot, the recommended approach is to keep at least one Super Admin exempt from the SSO requirement. If the IdP is down, that administrator can sign in with a HubSpot account and temporarily turn off the SSO requirement for other users.
Does SSO work with mobile apps?
It can, but support depends on the CRM, mobile app, IdP, and authentication protocol. OIDC is commonly used for modern web and mobile authentication flows. Verify the exact mobile sign-in path for your CRM and IdP before rollout.
Launching a Connected CRM With SSO
CRM SSO and SCIM solve related but separate problems: SSO centralizes authentication, while SCIM automates user-account lifecycle management. Used together, they can reduce sign-in friction, automate parts of onboarding and offboarding, and centralize more identity controls. A safer rollout starts with a pilot, validates role and permission mapping, enforces MFA at the IdP, tests deprovisioning, and documents a fallback path before SSO becomes mandatory.
HubSpot’s SAML-based SSO and SCIM provisioning follow this same pattern on eligible Professional and Enterprise subscriptions, with provider-specific setup requirements and provisioning caveats. If your team is evaluating a CRM with centralized authentication and provisioning in mind, Smart CRM is a practical place to start.