Hacker News Reader

Comment by scott_w | Hacker News Reader

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 looking at a request this morning where the error message is coming from Azure itself and clearly says “this is not configured correctly.” The request hasn’t even reached our systems yet!

Until SSO is as plug n play for users as Google Sign-in, SSO will continue to attract a high price point. And I’ll continue to push back on attempts internally to democratise it.

View on HN

I feel like a lot of the issues are also due to Azure making it vastly more difficult than necessary to configure OIDC/SAML and get the right information over to the SP.

I don’t doubt that, however the vendor doesn’t get a choice over the IDP and Azure isn’t even the worst! Last week we had to create a custom Metadata XML file for a customer because their IDP doesn’t accept self-signed certificates. For a certificate we send them. That we can validate on a call with them. And it’s completely undocumented in their IDP’s docs.

That shouldn't mean that you lock the feature out for customers that do have someone that can troubleshoot it/get it up and running without help.

Lock support for SSO up behind a paywall, not the actual feature.

What do you do when the customer locks themselves out? We have a good reputation for support so suddenly throwing up “sorry, no” will tank that.

This still doesn’t override positioning. Companies can make more money by charging more money for it, so they do.

"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."

And when you have to unlock it for the fifth time? This is looking like a shit product and shit customer support.

The customer misconfigured their SSO 5 separate times? Sounds like you don’t want that kind of customer in the first place to be honest.

Azure AD or whatever they are calling is now isn't even fully SAML 2.0 compliant, so of course it generates support calls. Then the answer from MS support is "use this workaround" and now your implementation is locked into Microsoft's implementation.

Sound familiar?

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.

> 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.

SAML is way more of a beast to configure and maintain compared to any oauth-based flow. One reason is just that SAML is more complex, because it does a great many different things for many different use cases. The other reason is that setting up SAML requires humans to coordinate the trust setup and key exchange between the IDP and Relying Party. For typical setups, oauth is pretty much self-serve, but where I worked setting up a new SAML customer required a senior engineer to personally handle it every time.

> 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, but giving access to SMBs strengthens the global security landscape.

> 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?”

Reply on news.ycombinator.com