Feature · SSO and SAML

Enterprise SSO for the CRM, shipping on the Strkr roadmap.

SAML 2.0 and OIDC federation with Okta, Azure AD, Google Workspace, and Ping. SCIM 2.0 provisioning, just-in-time user creation, enforced-SSO tenant mode, session-length controls, and an append-only audit log of every authentication event. On the near-term roadmap next to Verified Domains and MFA.

Start free trial See pricing
What enterprise SSO in a CRM actually means

The checklist buyers run every CRM vendor through.

Every CRM vendor claims SSO support. The useful question is which parts of the identity story are production ready, which are gated behind an enterprise tier, and which are a glossy marketing page over a half-shipped integration. In 2026, the buyer checklist for a credible enterprise identity integration is a specific list: SAML 2.0 and OIDC support, Okta and Azure AD and Google and Ping as named identity providers, SCIM 2.0 for provisioning and deprovisioning, just-in-time user creation on first sign-in, an enforced-SSO tenant mode that locks out password-based login, admin-configurable session length, step-up and session rotation controls, and an append-only audit log that captures every authentication and provisioning event with the identity provider request identifier attached. Strkr has the live-today pieces (session policy, password policy, IP allowlist) and the shipping-soon pieces (SAML, OIDC, SCIM, Verified Domains, MFA) on the roadmap. The checklist below is the one every security team should walk every vendor through before signing. The sections after it describe what Strkr already supports, what is landing in the near-term release train, and the design choices that shape the final feature.

SAML 2.0 federation

The identity standard every enterprise IdP supports.

SAML 2.0 is the universal protocol for enterprise identity federation. Strkr speaks SP-initiated and IdP-initiated SAML, consumes the standard assertion attributes, validates the signing certificate, and honors the NameID and attribute mappings your IdP admin configures. Every modern identity provider ships SAML templates, so the setup is import-metadata-file-and-done rather than a bespoke integration project.

OIDC federation

The modern protocol for cloud-native IdPs.

OpenID Connect sits on top of OAuth 2.0 and is the preferred federation protocol for cloud-first identity providers. Strkr accepts an OIDC issuer URL, client id, and client secret, discovers the endpoints from the standard well-known document, validates the ID token signature against the IdP's JWKS, and maps the standard claims onto the Strkr user record. OIDC also powers the integration with Clerk, Google Workspace, and any provider that prefers a token-based flow.

Okta template

A one-click application in the Okta catalog.

Okta is the dominant enterprise identity provider in North America. Strkr ships a prebuilt Okta application template that lands in the Okta catalog with sensible defaults for the attribute statements, group assignments, and SCIM endpoint. Okta admins search for Strkr in the integration network, add the app, assign a user group, and the federation is live in under five minutes with no custom XML editing required.

Azure AD and Entra ID

Enterprise app registration with SCIM.

Microsoft Entra ID (formerly Azure Active Directory) is the identity backbone for most Microsoft 365 shops. Strkr ships as an Entra enterprise application with SAML and OIDC templates and a validated SCIM endpoint. Entra admins assign the application to a security group, map the Entra attributes to the Strkr fields in the standard provisioning UI, and users land in Strkr the first time they visit the sign-in page.

Google Workspace

Native Google OIDC and SAML support.

Google Workspace customers can federate through either Google's OIDC provider or the Google Workspace SAML app catalog. Strkr accepts both and maps the primary Google identity (the Workspace email address) onto the Strkr user. For teams running Google as their directory of record, the full identity flow stays inside the Google admin console and the sign-in page defers to a Workspace prompt.

Ping and generic SAML

PingFederate, PingOne, and any SAML 2.0 IdP.

Ping Identity is common in financial services and other regulated verticals. Strkr ships a Ping-tested SAML profile and accepts the Ping metadata document directly. Beyond Ping, any identity provider that speaks compliant SAML 2.0 (OneLogin, JumpCloud, Rippling, Keycloak, Duo SSO, Auth0) can federate using the generic SAML flow with a metadata URL or an uploaded XML file.

SCIM 2.0 provisioning

User lifecycle driven by the identity provider.

SCIM is the standard for pushing user creation, update, and deactivation events from the identity provider into the downstream application. Strkr speaks SCIM 2.0 with the standard User and Group resources. When your IdP admin adds a new hire to the Strkr-assigned group, the user record appears in Strkr. When the admin removes them, the record is deactivated. No manual CSV upload, no admin forgetting to deprovision a departed employee.

JIT user creation

First sign-in provisions the Strkr seat.

Just-in-time provisioning is the lightweight alternative to SCIM. The user is defined in the identity provider, assigned to the Strkr application, and the Strkr user record is created the first time they successfully authenticate. JIT skips the SCIM endpoint configuration for smaller tenants and still enforces the group-to-role mapping that comes down in the SAML assertion. Many teams start with JIT and layer SCIM in once headcount justifies the heavier integration.

Enforced SSO mode

Password login disabled at the tenant level.

Enforced SSO is the switch that turns a nice-to-have into a security control. When enabled, the tenant's sign-in page refuses password-based login entirely and routes every authentication attempt through the configured identity provider. Break-glass admin accounts stay available through a documented recovery path with multi-factor and audit-logged use. The result: a departing employee loses CRM access the moment their IdP account is deactivated.

How Strkr SSO is designed

Identity-provider agnostic, session-aware, audit-first.

Enterprise identity integrations fail in predictable ways. The IdP admin discovers a required attribute is missing from the vendor's assertion schema. SCIM provisioning quietly silently stops firing because the vendor rotated an API key without rotating the integration. Session length is a tenant-wide global instead of a per-role setting, and the security team settles for the stricter one at the cost of UX for everyone. The Strkr SSO architecture is designed around the specific failure modes that break identity integrations in production. Here is the shape of the implementation that is landing on the roadmap, and the design decisions that shape each component before it ships.

Provider abstraction

One integration surface, many identity providers.

The federation layer sits behind a stable provider interface. Okta, Azure AD, Google, Ping, and the generic SAML path all land through the same authentication flow and the same user-record write path. Adding support for a new identity provider is a template entry, not a code fork, and no provider gets a special code path that drifts from the rest. The uniform surface is what keeps session rotation, audit logging, and role mapping consistent regardless of which IdP a tenant chose.

Signed assertion validation

Every SAML assertion verified against the IdP certificate.

Strkr validates the SAML signing certificate on every assertion, rejects assertions that fail signature verification, and rejects assertions whose NotBefore and NotOnOrAfter windows do not include the current server time. Replay prevention compares the assertion identifier against a short-lived nonce store. The validation stack is identical across every supported identity provider so a Ping tenant and an Okta tenant get the same cryptographic guarantees.

OIDC token verification

ID tokens validated against the IdP JWKS.

OIDC flows resolve the identity provider's JSON Web Key Set from the standard well-known document, cache the keys with a short TTL, and verify every ID token signature on receipt. The verification also validates the issuer claim, the audience claim, the token expiration, and the nonce value embedded in the authentication request. Rotation of the IdP's signing key is picked up automatically through the standard JWKS refresh pattern.

Attribute to role mapping

IdP group claims drive Strkr role assignment.

The identity provider assertion carries a group or role claim. The tenant admin configures a mapping table from IdP group values to Strkr role identifiers. Users land in the right Strkr role on first sign-in, and role changes in the IdP flow through on the next sign-in or SCIM sync. No manual role-reassignment work after a promotion, no stale permission inheritance after a transfer, no admin forgetting that a departed manager still has forecast-edit access.

Session policy

Admin-configurable session length and inactivity timeout.

Session policy is live today in Strkr even without SSO. Tenant admins set the maximum session length and the inactivity timeout, and the enforcement runs on every request. When SSO ships, the policy extends to cover forced re-authentication against the identity provider at session end, so a user whose IdP account was disabled mid-session gets kicked out at the next session boundary rather than waiting until they close the tab.

IP allowlist

Tenant-scoped network-level access control.

IP allowlist is live today. Tenant admins define the CIDR ranges from which sign-in is permitted. Requests from outside the allowlist get a hard rejection before the credential or token is even evaluated. When SSO ships, the allowlist layers on top of the federation flow so that even a stolen IdP session cannot be used from a network the tenant has not approved.

Audit log

Every auth event recorded with IdP request identifiers.

Every authentication event, every SCIM mutation, every session termination, every enforced-SSO lockout attempt lands in the append-only audit log. Each record carries the Strkr user id, the identity provider id, the IdP request identifier, the source IP, the user agent, and the resulting outcome. Security teams can trace a specific sign-in from the IdP log straight through to the Strkr activity trail without a correlation query that spans two separate systems.

Tenant isolation

One IdP configuration per tenant, zero cross-tenant leak.

Every tenant has its own identity provider configuration, its own metadata document, its own SCIM endpoint, and its own audit stream. There is no shared SAML keypair across tenants and no scenario in which a misconfigured customer identity flow could land a user in the wrong tenant. The tenant boundary is enforced at the authentication-handler layer, not just at the data-access layer.

Break-glass admin

Password-based recovery that cannot be locked out.

A documented break-glass admin account stays available even in enforced-SSO mode. The recovery path requires a second factor, logs every use to the audit stream, pings the primary tenant admin on each use, and gets automatically disabled after a configurable idle window. The pattern lets a security team confidently enforce SSO everywhere else without the fear that a misconfigured IdP cutover will lock the tenant out permanently.

Identity provider support, roadmap view

What is landing when, and in what order.

The honest grading of an SSO roadmap is which identity providers get first-class templates, which get the generic SAML path, and which are deferred to a later cycle. The Strkr sequence is designed around the identity providers the first paying tenants use. The order below reflects the shipping priority, not an aspiration list, and every item on this list sits in an active engineering slice.

Okta

First-class template at launch.

Okta is the dominant enterprise identity provider and the first integration to receive a prebuilt catalog application. Admins add Strkr from the Okta catalog, assign a group, and the federation is live in under five minutes. Group-to-role mapping, SCIM endpoint, and signed-assertion validation all ship in the same slice.

Azure AD and Entra ID

First-class template at launch.

Microsoft Entra ID is the identity backbone for most Microsoft 365 shops and ships alongside Okta as a first-class template. SAML, OIDC, and SCIM all land together. The provisioning flow uses the standard Entra attribute mapping UI, and the SAML template preloads the right attribute statements for the Strkr role claim.

Google Workspace

First-class template at launch.

Google Workspace customers can federate through either OIDC or the Workspace SAML app catalog. Both paths map the primary Google identity onto the Strkr user. For teams running Google as the directory of record, the identity story stays inside the Google admin console and the Strkr sign-in page defers to a Workspace prompt.

Ping Identity

First-class template at launch.

Ping is common in financial services, insurance, and regulated verticals. The Ping template covers PingFederate, PingOne, and PingAccess. The SAML profile is Ping-tested and the metadata ingestion flow accepts a Ping-exported document directly without manual editing.

Generic SAML 2.0

Any compliant IdP at launch.

Beyond the named providers, any SAML 2.0 compliant IdP (OneLogin, JumpCloud, Rippling, Keycloak, Duo SSO, Auth0) federates through the generic SAML flow. Tenant admins paste the metadata URL or upload the XML file, and the configuration validates against the SAML schema before saving.

Generic OIDC

Any compliant OIDC provider at launch.

Any OpenID Connect compliant provider federates through the generic OIDC flow. The admin pastes the issuer URL, client id, and client secret, and Strkr discovers the authorization, token, and userinfo endpoints from the standard well-known document. Supported for internally hosted Keycloak, Dex, Authentik, and any provider that follows the OIDC Core 1.0 spec.

SCIM 2.0

Lands with the first-class templates.

SCIM 2.0 provisioning ships in the same release train as the Okta, Entra, Google, and Ping templates. The endpoint speaks the standard User and Group resources, supports create, update, deactivate, and reactivate operations, and surfaces every mutation in the audit log with the IdP request identifier attached.

Verified Domains

Shipping alongside SSO.

Verified Domains lets a tenant claim DNS ownership of an email domain so that any user signing in with an address at that domain is automatically routed through the tenant's SSO configuration. The verification runs via a DNS TXT record, matches the hygiene already in place for custom-subdomain tenants, and prevents the "which tenant does this email belong to" collision at sign-in.

The identity-pricing trap

How CRM vendors turn SSO into a seat-tier upsell.

The SSO pricing problem is not whether SSO exists in the product. It is where SSO sits on the tier ladder. Industry-wide, the pattern is to lock SSO behind the Enterprise seat, often doubling the per-seat price for every user in the tenant purely to enable a security control the IT team is required by compliance to enforce. The practice is widespread enough to have earned a name (the "SSO tax") and a dedicated website that catalogs the markup across hundreds of SaaS vendors. The Strkr pattern is the opposite shape. SSO ships on paid tiers without a dedicated Enterprise-only gate, so the security control is reachable by the teams that actually need it rather than only the teams whose procurement budget can absorb the markup.

The SSO tax

A security feature priced like a luxury.

Across the industry, enabling SAML SSO routinely requires moving to a seat tier that is two to four times the Professional price. The markup is not driven by implementation cost (SSO is table stakes engineering) but by the leverage the vendor has over a buyer whose security policy mandates the feature. The practice converts a baseline security hygiene control into a line item on the budget review.

Salesforce

Enterprise edition minimum for SSO.

Salesforce supports SAML broadly across editions but the full identity feature set (My Domain, delegated authentication, external identity federation) effectively requires Enterprise edition pricing. For a growing team on Professional, moving to Enterprise purely to turn on SSO can double the annual CRM spend before adding a single new seat.

HubSpot

Enterprise-tier gate on the Sales Hub.

HubSpot Sales Hub gates SSO behind the Enterprise seat tier. Teams on Professional (where most SMB and lower-mid-market teams live) cannot enforce SSO without a tier jump. The Enterprise price step is substantial enough that many teams defer the SSO rollout past their security review deadline.

The hidden integrator cost

SSO you can buy but not configure yourself.

Some vendors ship SSO but require a certified consultant for the initial setup, which adds a four-to-five-figure services line to the SSO rollout. The licensing cost is only part of the total. Strkr's SSO configuration is admin-UI driven: an admin pastes the IdP metadata, maps groups to roles, and tests the flow without a vendor services engagement.

Microsoft Dynamics

Entra ID native, strong on Microsoft stacks.

Dynamics is natively tied to Entra ID, which is a strong fit for Microsoft 365 shops and a weaker fit for teams running Okta or Google as the directory of record. The identity story is excellent inside the Microsoft estate and friction-heavy outside it. Strkr's multi-IdP support treats every provider as a first-class target.

Pipedrive and Zoho

SSO present but gated at the top tier.

Mid-market CRMs typically ship SAML support but reserve it for the top paid tier. The common pattern is Professional-plus-SSO-addon or Enterprise-only, with the practical effect that teams rolling out SSO absorb a meaningful per-seat uplift. The economics push teams toward partial deployments where SSO protects only the top-tier seats and the rest of the team keeps password access.

The compliance timing

SSO is often a SOC 2 Type II prerequisite.

For teams pursuing SOC 2 Type II, HIPAA, or ISO 27001, enforced SSO on the CRM is routinely a required control. The security review timeline is driven by the audit calendar, not the CRM renewal. Vendors that price SSO at a steep markup end up negotiating against a buyer's audit deadline, which is a dynamic the Strkr pricing model is designed to avoid.

Three enterprise SSO patterns Strkr is designing for

What the integration looks like on a real security review.

The product demo shows a sign-in flow. The production security review asks about the specific shape of three recurring workflows: new-hire provisioning, departing-employee deprovisioning, and incident-response forensic queries. Here is how each pattern lands with Strkr SSO once the roadmap ships.

New-hire provisioning

Hire date arrives, CRM access is already live.

HR adds the new hire to the Workday employee system. The HR-to-Okta sync creates the identity. The Okta-to-Strkr SCIM push creates the Strkr user with the right role mapped from the Okta group membership. On the hire's start date they open the laptop, visit the Strkr sign-in page, redirect to Okta, land in Strkr with the correct permissions. No manual CRM onboarding, no admin forgetting the territory assignment, no first-day friction while the rep waits on IT.

Deprovisioning on exit

IdP disable, CRM access gone the same minute.

HR files the termination. The HR-to-Okta sync disables the Okta identity. The disable event propagates to Strkr through SCIM and deactivates the user record. Any active Strkr session is invalidated at the next session boundary and locked out immediately in enforced-SSO mode. The departing employee cannot sign back in, cannot export pipeline data, and cannot forward activity notifications to a personal address. The audit log records the full chain with timestamps.

Forensic query on an incident

One audit stream, one correlation id.

Security asks: "Did this user sign in from an unusual geography on this date?" The Strkr audit log answers with the source IP, the user agent, the identity provider request identifier, and the matching timestamps. The security team correlates against the Okta log using the shared request identifier. The forensic query completes in minutes without a vendor support ticket or a correlation gap between the IdP log and the application log.

SSO on the Strkr roadmap. Session policy, password policy, and IP allowlist are live today.

The identity hardening features that ship today (session length, inactivity timeout, password complexity, IP allowlist, admin audit log) are available on every paid tier. The federation layer (SAML 2.0, OIDC, Okta, Entra, Google, Ping, SCIM 2.0, Verified Domains, enforced-SSO mode) is landing on the near-term roadmap next to MFA. Start the trial on the live-today controls and get notified the moment the federation features light up on your tenant.

Start free trial See pricing
Common questions

What buyers ask about this feature.

Is SSO available in Strkr today?

The identity hardening features that ship today include tenant session policy (configurable maximum session length and inactivity timeout), tenant password policy (complexity and reuse rules), tenant IP allowlist, and an append-only admin audit log. Enterprise federation (SAML 2.0, OIDC, Okta, Entra, Google, Ping) and SCIM 2.0 provisioning are on the near-term roadmap next to Verified Domains and MFA. The roadmap page tracks the exact shipping dates, and tenants on paid tiers are notified when the federation features land on their account.

Which identity providers will Strkr support?

At launch the first-class templates are Okta, Microsoft Entra ID (Azure AD), Google Workspace, and Ping Identity. Beyond those, any identity provider that speaks compliant SAML 2.0 (OneLogin, JumpCloud, Rippling, Keycloak, Duo SSO, Auth0) federates through the generic SAML flow, and any OpenID Connect compliant provider federates through the generic OIDC flow. SCIM 2.0 provisioning ships alongside the first-class templates and uses the standard User and Group resources.

Will Strkr charge extra for SSO on an Enterprise tier?

The Strkr pricing model does not treat SSO as a top-tier upsell. The federation layer is designed to ship on paid tiers rather than gated behind a dedicated Enterprise seat price. The specific tier mapping is published on the pricing page the moment the federation features light up. The design intent is that the teams whose compliance posture requires enforced SSO can reach the control without a two-to-four-times seat-price jump, which is the industry pattern often called the "SSO tax."

Does Strkr support SCIM provisioning or only JIT?

Both. SCIM 2.0 is the heavier integration that pushes user create, update, deactivate, and reactivate events from the identity provider into Strkr using the standard User and Group resources. Just-in-time provisioning is the lighter alternative that creates the Strkr user record on first successful sign-in using the attributes carried in the SAML assertion or OIDC ID token. Most tenants start with JIT, add SCIM once headcount justifies the heavier integration, and run both in combination to handle edge cases like preprovisioning a new hire before their first sign-in.

What happens to active sessions when a user is deprovisioned?

When the identity provider deactivates the user through SCIM or through a direct admin action, the Strkr user record is deactivated immediately. Any active session is invalidated at the next session boundary set by the tenant session policy. In enforced-SSO mode, the session is terminated on the next request and the user cannot re-authenticate because the IdP will refuse the federated sign-in. The audit log records the full chain with the SCIM mutation timestamp, the session termination timestamp, and the IdP request identifier.

How does enforced SSO handle emergency admin recovery?

Enforced SSO disables password-based sign-in for regular users but preserves a documented break-glass admin recovery path. The recovery account requires a second factor, logs every use to the audit stream, notifies the primary tenant admin on each use, and gets automatically disabled after a configurable idle window. The pattern lets a security team confidently enforce SSO everywhere else without the risk that a misconfigured IdP cutover permanently locks the tenant out of the CRM.

Related features

Pair this with...

Contact Management Custom Objects Workflow Automation AI CRM Reports

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing