The sign-in page is the thinnest part of a CRM to render and the heaviest part to get right. Strkr's sign-in is a workspace-aware SSO handoff with SAML, OIDC, Okta, Entra ID, Google Workspace, device trust, Face ID on iOS, and server-enforced session policies. The ten-second UX hides a serious identity posture.
When security and IT teams review a CRM sign-in, they are not grading the form; they are grading the posture behind it. The six items below are what shows up when a security review flags a horizontal CRM's auth as a procurement blocker.
Horizontal CRM vendors commonly gate SAML SSO behind the top tier, which makes a basic security requirement into a budget conversation. Strkr includes SAML and OIDC SSO on every paid tier because security is a baseline, not a line-item upsell.
A single global idle timeout cannot represent a mixed environment (reps on managed laptops at a desk, field reps on BYOD iPhones). Strkr lets the admin set idle lock per device class, per role, and per segment, with the SSO extension re-authenticating silently when a trusted device re-enters.
Without device trust, a stolen password opens the CRM from any browser. Strkr integrates device-trust signals from Okta Verify, Entra ID Conditional Access, and the Strkr iOS app so sign-in requires both the credential and the device posture. Unknown devices land in a step-up flow.
A one-size session policy treats a workspace admin and a part-time rep the same. Strkr publishes session-policy templates (standard, elevated, privileged) with configurable max lifetime, idle timeout, re-auth cadence, and device-change behavior. Admins carry shorter sessions by default.
SSO without SCIM is only half the integration. Strkr supports SCIM provisioning with Okta, Entra ID, OneLogin, and JumpCloud; new hires provision on the sign-in path through the IDP, with workspace role and team mapped from directory groups.
Thin audit trails fail SOC 2 and ISO reviews. Strkr logs every sign-in with actor, IDP, device fingerprint, IP, and session outcome; the log exports to the warehouse and streams to a SIEM via a documented syslog or HTTP endpoint. The security team answers forensic questions in minutes, not days.
The sign-in form is one entry point among several. The cards below are the surfaces Strkr supports and the identity primitives behind each.
The default sign-in flow asks for the workspace subdomain and redirects to the tenant's configured IDP (Okta, Entra ID, Google Workspace, or generic SAML/OIDC). The IDP completes auth; Strkr honors the session cookie and lands the user on their last-viewed record.
Teams that run their IDP as the identity portal can initiate sign-in from the IDP tile. Strkr accepts IDP-initiated SAML with the audience and recipient restrictions enforced server-side; replay-protection via assertion ID prevents stolen-assertion misuse.
Tenants without an IDP use password sign-in with mandatory MFA. MFA factors supported: TOTP (any authenticator app), WebAuthn (platform authenticators and roaming keys), and backup codes. SMS is deliberately not a supported factor for CRM sign-in.
Mobile sign-in rides ASWebAuthenticationSession on the Apple side and Chrome Custom Tabs on Android, handing control to the IDP inside a system-managed view. A biometric check on both platforms locks subsequent app opens behind an admin-tunable inactivity window.
Service-to-service access uses OAuth-provisioned tokens scoped per workspace and per permission set. Tokens rotate on a configurable schedule; a revoked token stops working within seconds across all app instances.
Partners and resellers sign in to a tenant's partner surface through the same SSO rails with scoped permissions. Partner sign-ins log distinctly from internal users; the audit cut by actor type is one query.
The IDP integration list is the first question a security team asks. Strkr ships the common ones with SCIM provisioning and tested group mapping.
Okta integration via SAML or OIDC with SCIM 2.0 group push for workspace role and team mapping. Okta Verify factors (push, biometric, security key) flow through; the Strkr iOS app honors Okta FastPass for device trust.
Entra ID integration with SAML, OIDC, and SCIM provisioning. Conditional Access policies (device compliance, location, risk score) apply to Strkr sign-in; non-compliant devices land in step-up without accessing records.
Google Workspace SSO via OIDC with directory sync for user attributes. Google-managed devices honor the device-trust signal; non-managed devices can be allowed or blocked per workspace policy.
Any SAML 2.0 or OIDC-compliant IDP works. Strkr publishes the metadata, the entity ID, and the ACS URL per workspace; the admin pastes the IDP metadata and verifies with a test sign-in. SCIM provisioning is available where the IDP supports it.
SCIM 2.0 creates and updates users on hire, moves them when directory groups change, and deactivates on offboard. Deactivation invalidates sessions on the next event delivery (seconds, not hours) and the user cannot sign in again until re-provisioned.
For tenants that do not want SCIM, just-in-time user creation on first SSO sign-in creates the workspace account from the IDP assertion. Role and team are set by directory-group claim; the admin reviews the first JIT batch and refines mapping if needed.
A clean sign-in is table stakes; the posture after sign-in is what distinguishes a serious CRM auth model. The cards below are the session-and-device primitives Strkr applies after a user is in.
Three session-policy templates: standard (reps, long sessions, idle lock in hours), elevated (managers, medium sessions, idle lock in tens of minutes), privileged (admins, short sessions, idle lock in minutes, re-auth on sensitive actions). Admins assign templates to roles.
Strkr fingerprints known devices with a long-lived device ID stored in secure storage. Known devices skip step-up on sign-in; unknown devices step up through the IDP's MFA or a Strkr-managed WebAuthn re-auth. The admin reviews known devices from the user's security page.
Sensitive actions (bulk export of PII, record delete, taxonomy change, permission change, API-token rotation) require a step-up re-auth within the last 10 minutes. The step-up uses the IDP's MFA or a Strkr-managed WebAuthn challenge.
When the IDP deactivates a user via SCIM, Strkr invalidates all active sessions within seconds. The next request from any client (web, mobile, API) returns an authentication failure and the client lands on the sign-in page.
For tenants in regulated industries, an IP allowlist restricts sign-in to approved CIDR ranges or VPN exit points. The allowlist applies to both web and API; a non-allowlisted IP sees a block page with the admin contact for exception requests.
Every sign-in logs actor, IDP, device fingerprint, IP, geo, user agent, step-up status, and session lifecycle. The log exports to the warehouse (Snowflake, BigQuery, Redshift, Databricks) and streams to a SIEM via syslog or an HTTP endpoint. The security team answers forensic questions in minutes.
An auditor reviewing CRM access controls asks a predictable set of questions. The cards below are the five that recur and how Strkr answers them from the sign-in audit log.
Every sign-in event carries actor, IP, geo (coarse city-level), user agent, and IDP. The auditor filters by period, actor, or geo and exports the result. Answering "who signed in from a non-standard geography last quarter" is a single query.
The sign-in event carries the MFA factor used and the policy that required it. A missing factor fails the audit; Strkr's default policy requires MFA for every sign-in and the override path is admin-only and audited.
The live-session view lists open sessions by user and device with last activity timestamp. The admin terminates individual sessions or all sessions for a user. The termination logs an event and the client sees the failure on the next request.
For departed users, the audit shows the SCIM deactivation event, the session-invalidation events, and the final sign-in. The time between deactivation and session invalidation is logged; the SLA is seconds, not hours.
Sensitive-action events log the step-up status and the re-auth timestamp. The auditor cross-references with the data-export log to confirm every export was preceded by a fresh step-up.
Partner sign-ins and API-token usage carry distinct identity markers. The audit cut by actor type (internal, partner, service) is one filter; the token-scope used on each API call is on the request log.
The security team's questions are concrete; the comparison is concrete.
| Feature | Strkr | Horizontal CRM auth |
|---|---|---|
| SAML and OIDC SSO on every paid tier | Included | Top-tier upsell common |
| SCIM provisioning | Okta, Entra, OneLogin, JumpCloud | Varies; often top-tier |
| Device trust and known-device bypass | Fingerprint + IDP signal | Rare |
| Session policy templates | Standard, elevated, privileged | Global one-size |
| Step-up on sensitive actions | Export, delete, admin changes | Not enforced |
| SMS as MFA factor | Deliberately not supported | Common |
| WebAuthn passkeys and roaming keys | Supported | Varies |
| IP allowlist per workspace | Yes | Enterprise-only |
| Audit export to warehouse and SIEM | Native + syslog / HTTP | Limited |
| Session invalidation on SCIM offboard | Seconds | Minutes to hours |
Three common patterns for standing up Strkr auth against an existing identity platform.
An Okta-first org wires Strkr through Okta SAML with SCIM provisioning for role mapping and FastPass for device trust. Session policy templates get mapped to Okta groups so admins carry shorter sessions by directory membership.
A Google Workspace shop runs Strkr sign-in over OIDC with directory sync for user attributes. Google-managed devices get the known-device bypass; non-managed devices step up through a WebAuthn challenge.
An Entra ID shop with Conditional Access runs the full policy against Strkr: device compliance, risk score, named-location signals, and workload identity for API consumers. The combination enforces zero-trust on a CRM surface.
SSO on every paid tier. SCIM provisioning. Device trust. Session templates. Step-up on sensitive actions. A full audit log.
Yes. Strkr supports SAML 2.0 and OIDC on every paid tier with native integrations for Okta, Entra ID, Google Workspace, OneLogin, JumpCloud, Ping, and Auth0, plus generic SAML and OIDC. SCIM provisioning is available where the IDP supports it.
MFA is required by default for every sign-in. Supported factors: TOTP from any authenticator app, WebAuthn with platform authenticators (Face ID, Touch ID, Windows Hello) and roaming security keys, and backup codes. SMS is deliberately not supported as a factor.
Three session-policy templates (standard, elevated, privileged) carry different max lifetime, idle timeout, and re-auth cadence. The admin assigns templates to roles. On a handset or tablet, a biometric unlock reasserts identity once the configured inactivity window elapses.
Yes. Sensitive actions (bulk export, record delete, taxonomy change, permission change, API-token rotation) require a step-up re-auth within the last 10 minutes. The step-up uses the IDP MFA or a Strkr-managed WebAuthn challenge.
A SCIM deactivation invalidates all active sessions within seconds. The next request from any client (web, mobile, API) returns an authentication failure. The user cannot sign in again until re-provisioned.
Strkr is HIPAA compliant with a BAA available on request. SOC 2 Type II is in progress with completion targeted for Q4 2026. GDPR and CCPA controls are in place. The sign-in audit log exports to warehouses and streams to SIEM via syslog or HTTP for ongoing compliance evidence.
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.
