I get that it's for differentiation between plans, but as a customer it feels weird to walk into this pricing black hole just for SSO. Maybe you have some experience with that?
This is incorrect.
If anything, small companies need SSO more than any others - those companies usually outsource a lot (SaaS vs a dedicated hire), managing credentials is annoying.
Lots of people live without things others observe they need. Doesn't make going without a good idea.
> Companies that actually need SSO are the ones that have internal or external compliance requirements...
This logic is backwards.
Why do you think SSO is a "requirement" that security certifications or compliance policies look for? Why did that come to be? Who does SSO benefit? Are those personas relevant for only large companies or small ones too?
Do beginning drivers not “need” seatbelts or brakes? Or are these devices only needed to avoid tickets and pass inspection?
I’ve gone through a few “migrations to SSO” after years of non-SSO with customers in the past and it’s a fucking expensive nightmare.
Yet the customers still paid, so it was worth for them.
Don’t get me started on the services that have their own smart ideas on what constitutes a safe password. Max 8 characters with no repeated letters and of which 4 must be an emoji, with automatic logout every 12 minutes. Yes those still exist.
Password policies are things you want control over in your IdP to avoid all this BS. SSO really should be standard.
Says who?
In reality, users don't care. Regulators, however, sometimes do, which leads to certifications and compliance requirements - and only then SSO and MFA become non-negotiable.
Storing ClientID and ClientSecret for OpenID, or some keys for SAML per customer is much easier, and a lot less risky.
After all, I'm in the business of solving (insert SaaS problem), not in the business of solving authentication.
Some customers use Okta; great! But some of those customers have Okta configured in ways that don't work with your auth service. Some customers use Okta as a downstream to their _actual_ IdP, which could be Keycloak (a million different ways to configure that) or, god forbid, some custom thing they wrote. You've gotta support that.
Some customers (the ones that will pay the REALLY big bucks) use Active Directory Federated Services and SAML-based auth. SAML is XML/SOAP. Gigantic pain. Gotta support it.
Some customers want LDAP/LDAP-S based auth. Gotta support that.
Given all this, it makes much more financial sense to lock that behind customers who are willing to pay the big dollars for enterprise-y features AND support instead of dealing with infinitely long support tickets.
[0] There is no such thing as a happy OAuth2 flow.
LDAP is harder, but IMO you dont need it unless you operate in a very specific industry.
Offering SSO as part of an enterprise SKU offering implies there is a high-touch relationship out of the gate, and that there is a higher chance of success and adoption, including getting SSO set up right.
Furthermore many large behemoth corporations have strange SSO configurations and it's not unusual to require bespoke configuration let alone debugging time.
But "Sign in with..." or "Continue with..." M365 and Google gets you almost all SMB, and with Apple gets you individuals who spend money.
Add a domain check and you have the quick and dirty equivalent of SAML SSO without any touch at all.
People are currently implementing a simple self-service for common SAML and OIDC providers, like O365 and such. This will be free and recommended for all customers to use, because I believe in providing actual security for our customers.
And then you can order a consulting project on top to figure out a good way to import user groups, user identities and such into the platform, and ideally to integrate our preferred group structures with a customers existing approval and group structures. This also includes help to initially connect us to the IDP. This is priced at a relatively cheap consultant level.
And then there is a second tier of consulting projects if the customer is using a non-standard IDP and can't do it on their own. Like, we have one customer that has an in-house developed SAML provider, but the original people who worked on it aren't there anymore. That was an interesting project and I learned way more stuff about SAML than I ever wanted, and also fixed a bug in their SAML provider code. This is priced right between "subject matter experts" and "no".
That's what I consider a very fair split. Simple SSO for everyone, especially on standard providers. And if you want to save a day or two of your identity and authentication teams, you can hand us some cash to do so. Smaller customers generally won't need this, they usually just have 1-2 groups they want to push and that's easy to do, but large customers with complex directories and many users in different departments like these projects a lot.
But it's silly paying more than a FTE's salary just for the SSO tax when you've got 5 people.
"Price discrimination" is a pricing strategy where very similar products are sold at different prices in different market segments.
Imagine you've invented an amazing silver bullet that makes software developers 30% more productive.
For the likes of Google who pay developers $200k/year, getting 30% more productivity would be a great deal even if you were charging them $10k per user per year, because that productivity boost is worth $60k.
For unpaid students, casual users, open source projects and cash-strapped micro-businesses - a 30% improvement in $0 is still $0 so they can't afford much. Maybe $50/user/year, and they'll still complain like hell about it. But it'll help your tool spread and build word-of-mouth.
So how do you price your product - $50 or $10,000?
With "price discrimination" you can do both. Offer a cheap tier for home users and micro-businesses, and an enterprise tier with features Google desperately wants, at a much higher price.
By having prospective customers call for pricing, your sales folk can research each customer and figures out whether they're the kind of place that pays their developers $200k/year or more like $30k/year - allowing them to figure out how much the product is worth to that particular customer.
Unpopular opinion - you may like to call it an SSO tax, but I think it's perfectly reasonable from both sides. The reality is - if you're a 10 person startup and the "SSO tax" is annoying, then simply don't do the SSO version...you have 10 people in your company, you can get them all to use a password manager with MFA. If you're worried about security then fine, don't you think it's worth paying a little more?
If people's issue with the "SSO tax" is that the SaaS software provider is making incremental money for very little effort/investment, then I would love to explain how the economics of most SaaS tenancy models work with regards to infrastructure spend...
It's a bunch of handwaving to try to get price discrimination for a "how the Internet is supposed to work" standard everyone, even a single dev client of the SaaS, should be using.
And that the SaaS provider should be pushing so they don't have the liability of subscriber credential database protection ...
Having assessed 600+ software companies (many of which are 5-50 employees), I'd say about half of them use MFA consistently across their business. And it's not a budgetary issue, but more of a logistic/IT/prioritization one.
This is literally not the case. The pricing is nowhere near 50x - in fact if you negotiate the rates are only marginally higher than the tier below it.
FWIW - the sentiment I get here is that the gripe isn't necessarily the pricing (you notice how no one has quoted specific increases?) but that they have to pick up the phone to talk to someone for what they believe to be such a small feature.
> There are many 100 person scale ups that are pre-profit for who the hassle of managing separate accounts for X SaaS tools for 100+ people
So you're telling me that a company is complaining that they have to pay extra money for features that reduce their administrative burden and limit their risk, thereby costing them less money? Explain that one to me...
> There are many 100 person scale ups that are pre-profit
Also, put yourself in the seat of the owner of a software provider, would you rather win the sales opportunities of 10,000s of businesses that aren't pre-profit or the hundreds of businesses that match your criteria? I know who I'd be marketing to...