# SSO and SAML Explained Without the Jargon If you've ever evaluated enterprise software, you've been asked: "Do you need SSO?" Followed by a discussion involving acronyms like SAML, OIDC, IdP, SP, and SCIM. Most decision-makers nod along and add "SSO required" to their RFP without fully understanding what they're asking for. That's fine for procurement. But if you want to make a genuinely informed decision, here's what these terms actually mean. ## What SSO Actually Is Single Sign-On (SSO) means your employees log into one system (like Microsoft Entra ID or Google Workspace) and automatically get access to all connected applications. No separate passwords. No separate login pages. One authentication event unlocks everything. Without SSO, a company with 15 business applications means 15 usernames and passwords per employee. The result: password reuse, sticky notes on monitors, and IT helpdesk tickets for password resets consuming 30-40% of all support requests. With SSO, one strong password (ideally with multi-factor authentication) protects everything. ## SAML: The Enterprise Standard SAML (Security Assertion Markup Language) is a protocol that makes SSO work between different organizations and applications. It's been around since 2005 and is the default for enterprise authentication. Here's how it works, stripped of all technical jargon: 1. **Employee visits your platform.** The platform recognizes them as belonging to your organization (usually from their email domain). 2. **Platform redirects to your identity provider.** The employee sees their company's familiar login page (Microsoft, Google, Okta, etc.). 3. **Employee authenticates.** Using their company credentials, biometrics, MFA — whatever your organization requires. 4. **Identity provider confirms to the platform.** "Yes, this person is who they say they are, and here are their attributes (name, email, department, role)." 5. **Platform grants access.** Based on the identity provider's confirmation, not on a platform-specific password. The employee never creates a separate account. The platform never stores their password. Your IT team controls access from one central place. ## OIDC: The Modern Alternative OpenID Connect (OIDC) does the same thing as SAML but uses a more modern protocol built on top of OAuth 2.0. It's simpler to implement, works better with mobile apps, and uses JSON instead of XML. For most practical purposes, SAML and OIDC achieve the same goal. SAML is more common in traditional enterprise environments. OIDC is more common in modern SaaS platforms. The best platforms support both. ## Why SSO Matters Beyond Convenience ### Security Without SSO, an employee who leaves your organization might retain access to dozens of applications until each one is individually deprovisioned. With SSO, deactivating their company account immediately revokes access to everything connected. This is called "single point of revocation" and it's the most important security benefit of SSO. The average organization takes 7 days to fully deprovision a departing employee across all applications. With SSO, it takes seconds. ### Compliance Regulated industries (finance, healthcare, government) require audit trails of who accessed what and when. SSO provides centralized authentication logs. Every login, every session, every application access is recorded in one place. ### User Experience People underestimate how much password fatigue affects productivity. Employees at companies without SSO spend an average of 12 minutes per day on authentication-related activities — logging in, resetting passwords, dealing with MFA prompts across multiple apps. With SSO, that drops to under 2 minutes. ## SCIM: The Automation Layer SCIM (System for Cross-domain Identity Management) handles user provisioning — automatically creating, updating, and deleting user accounts in connected applications based on your directory. Without SCIM: Someone joins your company → IT manually creates accounts in 15 applications. With SCIM: Someone joins your company → They're added to your directory → SCIM automatically creates their accounts in all connected applications with the right roles and permissions. The combination of SSO (authentication) and SCIM (provisioning) is what enterprise IT teams actually need. SSO without SCIM means you still manage user accounts manually in each application. ## Evaluating SSO Support in Platforms Not all SSO implementations are equal. Here's what to verify: **Protocol support.** Does the platform support SAML 2.0 and OIDC? Supporting both gives you flexibility regardless of your identity provider. **SCIM support.** Can you automate user provisioning, or do you need to manually manage accounts? **IdP compatibility.** Has the platform been tested with your specific identity provider (Microsoft Entra ID, Okta, Google Workspace, OneLogin)? **Attribute mapping.** Can you map directory attributes (department, role, location) to platform roles and permissions? **SSO enforcement.** Can you require SSO for all users, preventing password-based logins? A platform that supports SSO but can't enforce it has a security gap. **Pricing.** Some platforms charge extra for SSO — sometimes significantly. This practice, known as the "SSO tax," is controversial. Basic SSO should be a standard security feature, not a premium add-on. ## The SSO Tax Problem Many SaaS vendors gate SSO behind enterprise pricing tiers, effectively charging a premium for security. Typical markups range from 2x to 10x the base price just to enable SSO. This creates a perverse incentive: smaller organizations that arguably need security most are priced out of the most effective security measure available. When evaluating platforms, look for vendors that include SSO at all pricing tiers, or at minimum don't charge prohibitively for it. Security shouldn't be a luxury feature. ## Getting Started If your organization uses Microsoft 365 or Google Workspace, you already have an identity provider capable of SSO. The setup with a modern platform typically takes 30-60 minutes: 1. Create an application registration in your identity provider 2. Configure the SAML or OIDC connection in the platform 3. Test with a single user 4. Roll out to all users 5. Optionally enable SCIM for automated provisioning The most common surprise: "That's it?" After hearing about SSO for years, most organizations are surprised by how straightforward the setup actually is.