SAML in 2023: Still Here, Still Useful

May 16, 2023
Walter Manger
4 minute read

      SAML is old. It emerged in the early 2000s when the web looked different and enterprise security meant XML and long certificate chains. Today, OAuth and OIDC get the headlines. So why is SAML still everywhere?

      Because enterprises trust it, compliance demands it, and it actually does what it promises.

      What SAML Does

      SAML (Security Assertion Markup Language) is a protocol for exchanging identity assertions between an identity provider and a service provider. In human terms: your company’s identity system (like Okta or Entra) proves to a SaaS app “this person is alice@company.com and belongs to the engineering team,” and the app trusts that assertion and logs them in.

      A SAML authentication flow looks like:

      1. User tries to access a SaaS app
      2. The app redirects to your company’s identity provider
      3. Your IdP authenticates you (password, MFA, whatever)
      4. Your IdP creates a digitally signed XML assertion containing your identity claims
      5. Your browser POSTs that assertion back to the app
      6. The app verifies the signature and logs you in

      The assertion is signed, so the app knows it came from the IdP you trust. The assertion contains claims (name, email, groups) the IdP vouches for.

      Why Enterprises Prefer SAML

      Standardization: Every enterprise organization has an identity system (Active Directory, Okta, Ping). SAML is the lingua franca. If your SaaS provider supports SAML, you can drop it into your existing identity infrastructure with minimal friction.

      Auditability: SAML assertions include detailed metadata: who, when, what groups, what attributes. Enterprise security and compliance teams love this — you can audit every login.

      Control: Your identity system, not the SaaS provider, owns the source of truth. If someone leaves your company, you disable them in Active Directory once, and they’re immediately locked out of every SAML-connected app. No syncing needed.

      Compliance: Many compliance frameworks (SOC 2, ISO 27001, HIPAA) explicitly list SAML as an acceptable SSO mechanism. It’s battle-tested in regulated environments.

      SAML’s Trade-offs

      Complexity: SAML is verbose. Assertions are XML. Configuration involves certificates, endpoints, entity IDs, and metadata files. It’s not fun to set up.

      Not for delegation: SAML proves who you are. It doesn’t grant your app permission to access your data on your behalf. If your SaaS app needs to call Google Workspace APIs on your behalf, SAML alone doesn’t solve that — you’d layer OAuth on top.

      Mobile unfriendly: SAML relies on browser redirects and POST bindings. Mobile apps don’t fit the model as naturally as OAuth does.

      SAML Today

      In enterprises: Essential. If you’re building a SaaS product targeting enterprises, SAML support is table stakes. Most enterprise customers will require it as a condition of purchase.

      In startups: Rare until you land an enterprise customer. The cost of implementing SAML support is real, and early-stage companies usually defer it until the revenue justifies it.

      In the future: Not going away. OIDC is simpler and more modern, but enterprises aren’t ripping out their SAML infrastructure. The two will coexist — SAML for legacy and enterprise deployments, OIDC for new cloud-native systems.

      SAML + SCIM

      SAML proves who you are. But it doesn’t provision users. If a new employee joins your company, SAML doesn’t automatically create them in the SaaS app.

      That’s where SCIM (System for Cross-domain Identity Management) comes in. SAML handles authentication, SCIM handles provisioning. Most enterprise SSO implementations use both:

      • SAML for login
      • SCIM for user lifecycle (create, update, deactivate)

      We’ll dig into SCIM separately, but the key insight: SAML and SCIM are complementary, not redundant.

      When to Implement SAML

      If you’re building a SaaS product:

      1. Start without it. Most early customers don’t require SAML. Invest in core product.
      2. Add it when enterprise sales demand it. Dedicate a sprint to SAML once you have a customer who needs it.
      3. Use a standard library. Don’t write SAML yourself. Libraries like python-saml, ruby-saml, and node-saml are battle-tested.
      4. Plan for SCIM alongside SAML. Enterprises expect both. Implement them together.

      The Bottom Line

      SAML is old, but it’s not obsolete. It’s the lingua franca of enterprise identity. If you’re targeting enterprises, SAML support is non-negotiable. If you’re building a B2B SaaS product, plan for it early.

      And if you’re comparing SAML to OIDC, remember: they solve different problems. SAML is for authentication in enterprises with existing identity infrastructure. OIDC is for modern cloud apps that want OAuth’s simplicity with authentication bolted on.