The real world problems with SAML

Ted Spence

6 min read

·

Sep 22, 2026

--

Listen

Share

Understanding the flaws baked into a once-hopeful technology

Today on hacker news we read an article on the bad design principles of SAML — but SAML has even more fundamental usability problems.

In fact, technological bad choices are perfectly normal. Lots of products started out awful but gradually fixed their rough edges over time (for example, JavaScript, x86 processors, or any other tech you love to hate).

So for today’s article let’s talk about why SAML is a usability nightmare and what should replace it.

Press enter or click to view image in full size

The user lockout problem

The shortest argument against SAML is: Any mistakes you make with SAML will likely cause one or more users at your company to be locked out of a product. A few common problems are:

• Experimentation: In the IT field, it’s fairly common for people to play around with a product and try to set it up. Most configuration options can be toggled on and toggled off, while users get familiar with the product. But if you try to turn on SAML and it fails, you’re stuck!
• Identity Provider Configuration: Identity providers like MS Entra or Active Directory might require that users be a member of a group or have a specific role. A user with such a problem might get cryptic errors when they try to use the product, which customers often blame on the SaaS platform rather than their identity provider.
• Auto-provisioning: This is a much-beloved feature of SAML, but it’s not always a good idea. Some SaaS product can’t automatically add a new user the first time they log on. This could be for technical or contractual reasons: maybe the SaaS platform hasn’t implemented it, maybe your account has a fixed number of licenses, or something else.
• Renewal: SAML requires that the buyer upload a security certificate, and then regularly renew that same certificate. If the renewal does not happen in time, people are locked out, which leads to support costs for the seller and frustration for the buyer.
• Turning off SAML is hard: No matter what mistake you made, calling support to ask them to turn SAML off isn’t a walk in the park. Because SAML is a security feature, they will likely challenge you and ask you to prove your identity. They might ask you to fax a letter on company letterhead. Do you have letterhead? Does anyone?

Any one of these problems will be a nightmare both for the company using the product as well as the SaaS platform that has to answer your frantic support calls.

The email identity problem and “best practices”

Modern security best practices include the dubious advice that “If login fails, you can’t tell someone why it failed.” The theory is that if you give a user any information at all about an error, it makes life easier for hackers.

This is a problem, but especially a problem for SAML.

One of the most insidious problems with SAML is the “authoritative email address” problem. Consider this scenario:

• A user creates the account alice.smith@example.com and logs on via username and password.
• The user then sets up SAML for their account and enables it.
• When the user next logs on, they type in their email address — alice.smith@example.com— and the SaaS product redirects to their identity provider.
• The identity provider happily confirms Alice’s identity, and notifies the SaaS product that the user logging on is actually asmith@example.com.
• The SaaS product notes that asmith@example.com is not a valid user and rejects their login.
• Or: auto-provisioning might create a new user with the new email address, and now you’re paying for two licenses for Alice instead of one!

At this point the user is frustrated and angry, they are either locked out or paying for multiple accounts, and when they ask for help they keep getting the runaround. Yes, their email address is alice.smith@example.com. Yes, they are provisioned. Yes, they are logging in correctly.

Eventually they will deduplicate the accounts and resolve the problem, but the SaaS product is prevented by modern security “best practices” from telling the user that there is a discrepancy in their email address. Until the next time the user changes their authoritative email address, and the problem starts all over again.

Workspaces and SAML

Modern SaaS products often support the notion of a “workspace” or an “account” — a single email address can often have access to lots of different workspaces.

But SAML doesn’t really recognize this notion. SAML just provides a way to authenticate yourself.

So what happens when a company has two, three, or four different workspaces that all need SAML configured? Do they really need configurations for each one?

Third party problems with SAML

A common use case for SAML is a security checklist item: Your CISO will ask “Does this product require SAML for all users?” and will want to check the box for “Yes” in the response.

But what happens when you have a temporary contractor, say bob.jones@gmail.com, working on your product? You can’t really force Bob Jones to be locked to your workspace — maybe Bob contracts for a few separate companies.

Maybe Bob is willing to sign up to use your authentication system, which would allow SAML to work for this one contractor. But Bob may or may not want to receive email through your service. Now you have a situation where your local authentication system has a record of a user with an email address that’s outside of your corporate domain.

Why is this a problem? Well, what happens if you set up a “contractor” account within your identity provider for a person with the email address billg@microsoft.com, even if your company isn’t microsoft.com? Can you now spoof someone and log them in via SAML using any phony email domain?

In theory, the SaaS product should either allow third party emails only for that one workspace, or it should reject third party emails completely. But fundamentally this is a problem with SAML that is a burden for users to fix.

What would be better?

I’ll finish today’s article by explaining in a short summary what would be better, and I’ll note that this is probably very similar to what Matt Schwager writes in his article:

• Your domain name servers should have a TXT record that tells any SaaS product how to reach OAuth/OpenID for any email addresses at your domain.

The way this should work is fairly simple:

• When you create your domain, you publish a DNS TXT record with the text SSO: Google,https://myopenidprovider.com?parameters
• When any SaaS product logs on a user by their email address, the SaaS product should first look up the TXT record to see if an “SSO” element is present.
• If the SSO element contains a known provider — say, Google, Microsoft, Apple, Okta, or someone else — it should insist that the user not log on with username and password, but instead login via the specified OpenID/OAuth.
• If the SSO provider needs additional parameters or configuration to enable authentication to work, they can be specified after the comma.
• Finally, your SaaS workspace should have a rule that says “Only SSO users may log onto my workspace.” This would allow users on Gmail, for example; but it would lock out someone attempting to spoof an email via a SAML provider that doesn’t own their domain.

This would be better than SAML for a number of reasons:

• SaaS providers can identify the single-sign-on provider for a customer automatically.
• There is a definitive mechanism for rejecting a spoofed email address: if a SaaS site redirects to a login provider, and the email address that comes back isn’t from the correct domain, you can check the SSO record for that domain to see what the correct provider is.
• If someone mistypes their email or has an authoritative-email discrepancy, there’s a way to resolve it. As long as the SSO record is still definitive for their email address, they are legitimate.
• If the customer changes SSO providers, or cancels SSO, they can notify all SaaS products at once by changing their TXT record, rather than having to notify hundreds of applications separately.
• If a SaaS product has not yet implemented a specific SSO provider, they can detect that and gather statistics to see which SSO providers would add the most value for their customer base.

I’m sure you can think of other benefits. But yes, I agree with Matt: SAML was a nice idea that has long outlived its usefulness.

Ted Spence heads engineering at ProjectManager.com and teaches at Bellevue College. If you’re interested in software engineering and business analysis, I’d love to hear from you on BlueSky or LinkedIn.