Vendors who charge extra for single sign-on
sso.tax
sso.tax
Which kinda gives the game away, right? It’s not that SSO is a luxury feature but that it’s an IMMEDIATE signal that you’re dealing with an org that can afford to pay.
It’s absolutely a security feature but that doesn’t mean it should be free for any reason other than I don’t want to pay for it. So I wish them the best in bullying the companies into giving me free things. We just dropped $100k on a security product last week so I’m in the market for freeing up room in the budget.
It's one thing to say that some feature is actually adopted as a security requirement at many companies and that SaaS vendors who don't offer that feature will lose out on those companies as customers.
It's another thing to say that SaaS vendors are failing to meet a massive market requirement, and that companies on the other side of that market are also failing to "realize" and adopt that requirement. In other words, unless I saw evidence that a larger portion of 6-person companies demanded this feature, it seems reasonable to assume that the market simply doesn't want this feature, and SaaS vendors aren't doing anything particularly stupid by not offering the feature.
no, it was a core security requirement whether or not it was accepted as such. but it turns out that saving money wins out over security until you get owned OR you're making enough money to not care.
SSO is net good for security and is a quick way around a lot of red tape in certain regulatory domains but the value prop has always been, and still is, largely administrative.
Having a human manage the accounts of hundreds of people with 10+ logins each services each costs real money compared to adding an account once to AD and dropping them in the group with the rest of their team which is why companies, rightly, feel they can charge a pretty penny for the privilege. Small companies can afford rolling accounts by hand but then you grow and then you have to decide if it’s worth spending the employee hours or the cash.
The very last thing I want from my bank, insurance company, or what have you is for them to be handing over information about every login I make to Google or Facebook.
SSO isn't optional; startups of basically all sizes should be using it, almost from the jump. It's not a thing you're supposed to invest in when you finally hit, like, 100 employees or something; it's as important for a 5-person team as a 20-person team.
I get the concept of price discrimination and have no on-spec moral qualm with it. But charging extra for SSO is no different than charging extra for MFA; in fact, MFA as a feature is harder to deliver than SAML.
When my org tries to buy a new SaaS I try to get them to only budget/consider it at the lowest level that gives them SSO - if they can't afford that, then they can't want it enough...it works sometimes...
We've routinely deployed our softare to customers who pay us 7 figures. We have literally had to enable SSO only twice in the last 5 years.
There's a difference between _should_ and _actually does_.
So maybe we’re biased there. It never occurred to me that SSO would be used by smaller orgs so we never bothered putting that into our base pricing.
In fact, Raygun's policy (according to this list) sounds like something I would do: add support for a couple common ones like Google and Facebook, make all the other SSO setups require an Enterprise plan.
* note: I dealt mostly with higher-ed. Don't know if they're more or less competent compared with corporations.
If I need to use your SaaS’s identity system, you cannot afford to do business with me, because my company will bury you in red tape and liability.
Not the thesis of the article, this is taking down a straw man. The actual article says this:
>If companies claim to “take your security seriously”, then SSO should be available as a feature that is either:
>1. part of the core product, or
>2. an optional paid extra for a reasonable delta, or
>3. attached to a price tier, but with a reasonably small gap between the non-SSO tier and SSO tiers.
>Many vendors charge 2x, 3x, or 4x the base product pricing for access to SSO, which disincentivizes its use and encourages poor security practices.
From a value perspective? If you want the current woeful state of security to continue, sure, maybe you can argue that it's a good idea to charge more for tools to better secure a business's operations. But that sucks. We should be encouraging small businesses to properly secure their ops, because it very well may be our data that they're dealing with. And we shouldn't be encouraging service providers to make that harder.
Edit: I do agree with you that a lot of enterprise pricing can feel like the vendor simply figured out a % of your ebitda and decided it sounded good to them. But in the examples in the article, most enterprise pricing was fairly well documented / published. If you want to really get into some of the bad actors don’t look at the list from the article, look at the enterprise platforms that are easily into the hundreds of thousands per month... I won’t name names but if your an enterprise IT manager you know who they are.
Enterprises forcing their policies is pretty easy if they're an SP to your directory, FWIW. I've had great success with Okta for this, but I've written SPs that talk to arbitrary OIDC providers and it works pretty well too.
Does that make anything any better for the world?
And that's completely fine. You can have an enterprise tier with more features! What I am saying--and I understand that you understand this but for your question to have any rhetorical impact must misapprehend it--is that they must not be security-based features as it is full-stop unethical to charge a toll for basic security.
It’s like arguing that economy airline seating sucks and shouldn’t be allowed to be different than business class. Economy is subsidized by first and business. If you legislate away the difference, it’s not the case that everyone now gets a business class seat at the economy ticket price but much more likely that the other equilibrium emerges where only business class service and pricing is offered.
This shit is baseline. And if it continues to not be, it's time to get legislators involved. Because that's what we all want, I'm sure.
I’m sure there are cheaper solutions and we only use our setup for validation testing for our own SSO implementation where we are the SP.
Don't think of SSO as a "tax" you have to pay on top of what is otherwise a cheap and fair base price.
Rather, think of the enterprise price (which includes SSO) as the fair base price that allows the vendor to stay in business and pay their costs.
While everything else (non-enterprise) is severely discounted, in the hopes that if you do become enterprise you'll pay full price then.
And you need something to prevent enterprises who can obviously afford to pay, from buying 1000's of seats at discounted rates. So you discriminate based on something they absolutely need: SSO.
It works really well.
Yeah, SSO is a security feature and you expect to get security for free. But SSO is not free for us as the service provider. We pay a vendor (Auth0) a decent amount of money to handle all the hard stuff. We also have to manually set up SSO for each of our customers who want it, which can take anywhere between 10 minutes to several hours depending on whether the customer has set up SSO before. For these reasons, we charge an annual fee for SSO on top of the regular subscription fee. We're just not big enough to absorb the cost.
It takes us about two or three hours of coordinating with our client to configure SSO and that’s if they only use it for authentication. If they use it for authorization also where we base their permissions on claims they send us - as oppose to an admin in their side configuring their users - it’s a lot more coordination.
We host our own Ping Federate instances.
Your system becomes hard dependent on a piece of infrastructure outside of your control, frequently provided by some bad IT vendor. Failures on their side are always blamed on you & you spend tons of resources debugging their problems.
I’ll buy that SSO is a core feature but that doesn’t change the economics of it. It needs to require higher prices.
And even with SSO, your credentials don't have access to everything, because no one employee should have access to everything. People should only have access to the IM channels, git repos, etc that they are actually involved with. Admin accounts and especially critical systems should be set up to require separate/additional authentication.
On top of that now enterprise plans now require you to pay by connection as well. So if you want to allow multiple customers SSO connections the cost starts increasing drastically.
(SaaS with 5 to 500 logins per customer)
By this sentiment, does Let's Encrypt debase the value of security as well?
So Slack's "$6.67 per u/m" means each month you pay $6.67 for each user who has signed up. Your company has 20 users? You pay $133.40 each month.
Maybe I am misinterpreting this, but I have had this conversation quite a few times in the past month alone with other engineers and execs, and I have to take an entirely different stance.
If you are trying to bootstrap a SaaS start-up (or even if you arent and just want to be frugal and/or keep technical complexity low) I do not think that outsourcing your authentication to a third-party provider, especially at cost, is necessarily the best choice.
A) In the developer community chats I am in, the auth provider that pops up the most in conversation is Auth0. Personally, I do not see how they stay in business because their pricing is (in my opinion) egregious. $228/mo for 10,000 monthly active users. However, they do have a free plan up to 7,000 monthly active users. The sheer volume of people who continually bring Auth0 up means that they either build products which never gain significant traction & have never had to scale, or have money to blow. So there is the cost-factor argument.
B) While you can make the argument that the vast majority of people have accounts with SSO providers, I would play Devils Advocate and say that there also exist people who are uncomfortable either providing that identity regardless of the anonymity/security meaures in place, or because they do not want to associate an identity from a primary authentication provider with your site/service. So there is your please-the-people argument.
C) From a technical perspective it CAN be easier not to opt for SSO integration. What I mean by this is, for the past half-decade, the majority of the products I have built have used bcrypt-ed passwords. And that works just fine. For getting things off the ground you can go far with a solid password hash-and-compare implementation.
Something roughly like the following is free, super easy to implement, and covers a large percentage of usecases:
- Store password with an algorithm like bcrypt or Argon2 on sign-up, compare on login
- Opt-in 2FA by using OTP via SMS or email
- Issue a SecureRandom session token each time a user logs, and use it as the identifying mechanism in a JWT or similar
- Make your auth logic verify the JWT and look the user up by the session token
- You can emulate the blacklisting/all-token revoke functionality major auth providers have by clearing one/all session tokens in the DB
I am sure someone who knows much, much more than me about security show up in the comments below this and tell me I am idiot, but this is my two-cents at least ¯\_(ツ)_/¯
(Side note edit: I think that there is a burgeoning problem in the developer community where new engineers reach for the easiest thing and wind up with a stack full of nothing but X-as-a-service, which in this case includes authentication. I am not sure how many junior devs could implement basic password-hash JWT authentication from scratch. The fact so many of them are readily paying $2,500/yr per 10,000 users for JUST authentication is mildly terrifying)
$228/mo doesn’t even register. We probably spend a lot more for coffee in the office. (We’re much higher volume user than that, but the initial price point is just not something that would be a barrier.)