3 ms·

As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrat

As someone who deals with application support, another big reason is SSO is such a support nightmare. No one wanted to touch SSO tickets because of how frustrating they were to deal with. People wouldn't follow the instructions. Microsoft/Google moved something in their portal and we didn't know so instructions were useless. Microsoft/Google would be having issues and we got tickets because they were still working until tokens expired. Their Admins would turn on 2FA and when their support desk got "Cannot login to $OurProduct", they would just flip it over to us without caring. List goes on and on.

sparrish 2y ago
This is the real reason there's an SSO tax. It costs to support SSO, the customers who want SSO should pay for that cost.
- noleary 2y ago
  I would agree that this cost-plus pricing structure applies in some cases. Some companies definitely want to constrain the universe of SSO users. But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle. Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
- wmf 2y ago
  I thought some company had free SSO for Google and 365 only and advanced SSO on the enterprise tier. I don't remember which company though, so maybe I made this up.
- candiddevmike 2y ago
  There are plenty of folks who setup SSO with open source projects without a support contract. Why should they have to pay for it with other software?
  - sethops1 2y ago
    Because the engineers of the other software chose not to work for free?
    - candiddevmike 2y ago
      I'm not saying they shouldn't be compensated, just that justifying the SSO tax due to the support burden is pearl clutching.
      - antimemetics 2y ago
        Do you mean that the support burden is not a valid reason to charge for SSO? In my experience support us the most tedious, annoying, and time-costly part of building a SaaS so I would definitely always charge extra for anything that requires more support
  - fomine3 2y ago
    all functionalities are absolutely no warranty
- chgs 2y ago
  There’s a cost to support non sso authentication to.
  - sparrish 2y ago
    non-sso authentication isn't nearly as support intensive. Sure there are support requests for 'regular' authentication but it's usually the "I can't remember my email" or "I can't remember my password" type stuff - easy replies. SSO issues usually takes 10 or 20 times longer to sort out any issue.
SkyPuncher 2y ago
I was lead engineer for a startup. By virtue of being the most flexible in my day-to-day, I ran front line for most of the customer support issues. SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts. We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
- doctorpangloss 2y ago
  Yeah but does that require any expertise to solve? It’s a bunch of meaningless arcana, for which the other party pays well. Seems like a fair deal. Someday you might get big enough where it’s minions talking to minions, or so big that people simply accept no customer service as the status quo.
  - SkyPuncher 2y ago
    It depends. I certainly wouldn’t say it’s approachable. There are basically three major issues that require a bit of seniority to support: * it’s an auth controlling system so mistakes can mean significant data breaches. * there’s shared responsibility between provider and customer for configuration. Further, there are a lot of possible configurations to consider. * the concept behind SSO is largely simple, but the implementation can be very complex. It’s almost always specific to your auth system and controls.
t0mas88 2y ago
This it's exactly the issue with SSO and enterprise customers with complex requirements on how their IDP needs to be integrated.
- wkat4242 2y ago
  Meh. Most of them are using off the shelf stuff like Entra ID or Okta. They support complex configs but it's all on the side of the IDP. For the end service it's just SAML.
grinich 2y ago
The “human cost” of SSO is definitely the hardest part. At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems. It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.com/app/settings https://explore.workos.com/app/settings
- noleary 2y ago
  Oh cool! We have pretty much the same thing
  - greenstreet1994 2y ago
    how is yours different? curious to know
floren 2y ago
Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.
- seszett 2y ago
  > I'm convinced nobody actually understands SAML. That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time. Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well. I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
- jiggawatts 2y ago
  Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock. (Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
  - 7bit 2y ago
    > Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
crote 2y ago
That's why you charge extra for the White Glove Service turnkey support tier. Nobody's claiming every SaaS vendor has to spend days of support time handholding every single customer through setting up semi-custom SSO solutions - we're all just asking for the vendors to stop gatekeeping the basic off-the-shelf SSO implementation!

sparrish 2y ago

This is the real reason there's an SSO tax. It costs to support SSO, the customers who want SSO should pay for that cost.

noleary 2y ago
I would agree that this cost-plus pricing structure applies in some cases. Some companies definitely want to constrain the universe of SSO users. But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle. Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
wmf 2y ago
I thought some company had free SSO for Google and 365 only and advanced SSO on the enterprise tier. I don't remember which company though, so maybe I made this up.
candiddevmike 2y ago
There are plenty of folks who setup SSO with open source projects without a support contract. Why should they have to pay for it with other software?
- sethops1 2y ago
  Because the engineers of the other software chose not to work for free?
  - candiddevmike 2y ago
    I'm not saying they shouldn't be compensated, just that justifying the SSO tax due to the support burden is pearl clutching.
    - antimemetics 2y ago
      Do you mean that the support burden is not a valid reason to charge for SSO? In my experience support us the most tedious, annoying, and time-costly part of building a SaaS so I would definitely always charge extra for anything that requires more support
- fomine3 2y ago
  all functionalities are absolutely no warranty
chgs 2y ago
There’s a cost to support non sso authentication to.
- sparrish 2y ago
  non-sso authentication isn't nearly as support intensive. Sure there are support requests for 'regular' authentication but it's usually the "I can't remember my email" or "I can't remember my password" type stuff - easy replies. SSO issues usually takes 10 or 20 times longer to sort out any issue.

SkyPuncher 2y ago

I was lead engineer for a startup. By virtue of being the most flexible in my day-to-day, I ran front line for most of the customer support issues. SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts. We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.

doctorpangloss 2y ago
Yeah but does that require any expertise to solve? It’s a bunch of meaningless arcana, for which the other party pays well. Seems like a fair deal. Someday you might get big enough where it’s minions talking to minions, or so big that people simply accept no customer service as the status quo.
- SkyPuncher 2y ago
  It depends. I certainly wouldn’t say it’s approachable. There are basically three major issues that require a bit of seniority to support: * it’s an auth controlling system so mistakes can mean significant data breaches. * there’s shared responsibility between provider and customer for configuration. Further, there are a lot of possible configurations to consider. * the concept behind SSO is largely simple, but the implementation can be very complex. It’s almost always specific to your auth system and controls.

t0mas88 2y ago

This it's exactly the issue with SSO and enterprise customers with complex requirements on how their IDP needs to be integrated.

wkat4242 2y ago
Meh. Most of them are using off the shelf stuff like Entra ID or Okta. They support complex configs but it's all on the side of the IDP. For the end service it's just SAML.

grinich 2y ago

The “human cost” of SSO is definitely the hardest part. At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems. It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.com/app/settings https://explore.workos.com/app/settings

noleary 2y ago
Oh cool! We have pretty much the same thing
- greenstreet1994 2y ago
  how is yours different? curious to know

floren 2y ago

Yes! We don't charge for SSO, but thankfully we've only had our largest customers ask for it -- and every time it required significant back-and-forth to get it set up. Basically every time somebody comes in with a new IdP, I have to go stand up my own instance so I can figure out what weird combination of options will make it work, because I'm convinced nobody actually understands SAML.

seszett 2y ago
> I'm convinced nobody actually understands SAML. That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time. Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well. I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
jiggawatts 2y ago
Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock. (Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
- 7bit 2y ago
  > Nobody understands SAML because it doesn’t really exist. It’s not so much a standard as a bag of standard parts from which a protocol can be assembled. It’s possible for two implementations to be fully compliant and yet incompatible. I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.

crote 2y ago

That's why you charge extra for the White Glove Service turnkey support tier. Nobody's claiming every SaaS vendor has to spend days of support time handholding every single customer through setting up semi-custom SSO solutions - we're all just asking for the vendors to stop gatekeeping the basic off-the-shelf SSO implementation!