Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why SMBs Don't Deploy SSO

cisa.gov

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Why SMBs Don't Deploy SSO

#41

Post by hluska »

One of my friends from high school has a dad with a business. I still live in the same city where I went to high school so I occasionally get called to do some tech support for my friend’s dad. Last summer, he ended up in SSO hell and so I got loaded on muscle relaxants and went to help him.

He’s an excellent guy with a great attitude and a genuine love for what he does. He’s infectious and when I get to see him, I usually laugh so hard I damned near hyperventilate.

His SSO issue was so severe that all that good humour and attitude was totally absent. It took a couple of days, but we got him going.

I’m a big fan of democratizing tech, especially security tech. But SSO is quite complicated at the best of times. When it goes wrong, it’s like troubleshooting a plate of spaghetti where half the noodles try to bite you.

In the case of SMB, when it goes wrong their businesses mostly grind to a halt. They often don’t have dedicated IT staff - the model of a son’s friend who comes in to help because he didn’t move away is quite common in SMB.

It’s a good idea, but in practice until we can get it to be completely turnkey, I don’t believe that many SSO providers could even afford to provide support for SMBs.

Re: Why SMBs Don't Deploy SSO

#42

Post by justin_oaks »

scott_w wrote: post #6

As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was…

> Until SSO is as plug n play for users as Google Sign-in

I noticed that Slack offers "OAuth with Google" for their Pro plan (lowest paid tier) but SAML SSO requires the more expensive Business+ plan.

Would it make sense to allow everyone to use the "easy" SSO and require higher payment for stuff that's complicated and easy to screw up?

Re: Why SMBs Don't Deploy SSO

#43

Post by justin_oaks »

dswalter wrote: post #4

I'm largely in favor of SSO, but it's not without its downsides, going beyond capital costs: SSO can also be implemented in a way that introduces an onerous latency tax when using services.

> SSO can also be implemented in a way

Unless you're more specific, I'm going to assume that that "way" is the wrong way.

Initial login shouldn't add more latency than a couple web redirects. The authentication token/assertion should be validated only once and not be needed until it expires or the user logs out.

Re: Why SMBs Don't Deploy SSO

#44

Post by scott_w »

eastbound wrote: post #38
scott_w wrote: post #6

As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was…

> it’s seen as an enterprise product Seen? SMBs need to be SOC2 (et al., such as PCI-DSS or HIPAA), and the requirement of controlling all accounts’ permissions at all times is often fulfilled with SSO. How else would you “reset the user’s password after 3 attempts” if the attacker can try the password 3 times on… all of your intranet websites? let alone on Cloud products. SOC2 is indeed seen as an enterprise feature…

> SOC2 is indeed seen as an enterprise feature

Then charge your customer for it.

> but giving access to SMBs strengthens the global security landscape.

How does giving away an expensive-to-support feature “strengthen the landscape?”

Re: Why SMBs Don't Deploy SSO

#45

Post by scott_w »

lelanthran wrote: post #39
ArchOversight wrote: post #28

Earlier quoted context omitted.

Google Sign-In is locking people to using Google's infrastructure. If an SMB has already deployed using Azure you don't get access using SSO, instead you have to fall back to username/password? Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.

> Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult. Since it seems that you know what you are doing (and you've done it before), how about a blog post detailing the steps one would go through when writing some SaaS app for a client who wants SSO?

The issue isn’t writing the code. It’s everything that comes after in terms of user support. The systems are relatively easy to integrate with libraries or products like Auth0.

Re: Why SMBs Don't Deploy SSO

#46

Post by scott_w »

justin_oaks wrote: post #42
scott_w wrote: post #6

As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was…

> Until SSO is as plug n play for users as Google Sign-in I noticed that Slack offers "OAuth with Google" for their Pro plan (lowest paid tier) but SAML SSO requires the more expensive Business+ plan. Would it make sense to allow everyone to use the "easy" SSO and require higher payment for stuff that's complicated and easy to screw up?

That’s exactly what everyone does. Most even put Google Sign-in into their free plans because it’s a great way to increase sign-ups.

The main benefit of SAML comes from the permission management and standardisation across systems. Its also what starts to make it complex beyond just writing the code.

Re: Why SMBs Don't Deploy SSO

#47

Post by tatersolid »

Dachande663 wrote: post #30
jameskilton wrote: post #9

Full disclosure: I work at WorkOS ( https://workos.com/ ), we provide SSO (among other things) as a service. I glanced through the report and it comes to the normal conclusion that SSO is hard and expensive to get right. Do SMBs focus on providing value to their customers in the problem space that they are experts at or do they spend months just getting sign-in working? Yeah I get the concern about the "SSO tax" but…

We’re current users of workos, for both the SSO and directory sync (which I love) features, but unfortunately the pricing means we have to charge our customers more for it. SSO+DS exceeds the cost of our base plan leading us to having to look at other alternatives and move away eventually :(

Same here. As a SaaS provider to SMB, all the major auth vendors (Okta, Ping, WorkOS, etc.) are ludicrously overpriced and would require us to double our own pricing.

Except Entra ID for customers, which is fairly priced and has a magic “just works automatically for any M365 customer” feature. It is quite stupid and confusing in many other ways but at least it makes fiscal sense.

Re: Why SMBs Don't Deploy SSO

#48

Post by lelanthran »

scott_w wrote: post #45
lelanthran wrote: post #39

Earlier quoted context omitted.

> Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult. Since it seems that you know what you are doing (and you've done it before), how about a blog post detailing the steps one would go through when writing some SaaS app for a client who wants SSO?

The issue isn’t writing the code. It’s everything that comes after in terms of user support. The systems are relatively easy to integrate with libraries or products like Auth0.

> It’s everything that comes after in terms of user support.

That's the detail that I need, actually

Re: Why SMBs Don't Deploy SSO

#50

Post by bkuehl »

scott_w wrote: post #6

As someone who works on our SSO implementation, the reason for the SSO tax is twofold: - Positioning: it’s seen as an enterprise product so attracts enterprise pricing - Support: it’s genuinely a high touch feature which lots of customers fuck up all the time in the same way and always needs support and engineering help. Documentation for those issues? We have it, it doesn’t stop the support requests coming in. I was…

Thank you for explaining this so succinctly!

People just don't seem to understand that to do SSO properly and securely for your app it costs decent money and support time. Regardless of if you roll your own or buy 3rd party (recommended). We do include SSO by default but we really only sell to enterprises and the price is baked in. A lot startups won't have that luxury.

Post reply on HN