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