For those wondering what the "SSO Tax" is, it refers to the excessive pricing practiced by SaaS providers to access the SSO feature on their product.

A documented rant has made the rounds at https://sso.tax , which lists all vendors and their pricing of SSO.

I always thought this was insane, but now I wonder if "SSO Pricing"/tax is just the "real price" and the "Base pricing" is really the new free trial? Of course the SSO/real pricing is too high, and everyone negotiates it down, but the point is I suspect the "base pricing" is just a trial teaser that's probably not sustainable for many vendors in terms of margins. I'm just guessing here, maybe someone with some inside insight from one of these vendors can advise.

Great question, and as a vendor with multiple products that suffer from an SSO tax here is my $.02

As a small team we get constant requests to integrate with a customers SAML provider - eventually we just switched to https://workos.com/pricing We explain to our customers that we have a hard cost for the integration and we pass that cost to them directly. The SSO version of our product and our self signup product do the same thing the same way - it's the compliance or risk management requirement mandated by our customers that require that we sell it the way we do. In our case our SSO or Enterprise version is $125 more expensive than the self signup product. Our money is in the product itself not in the SSO.

So, uh, is that cost a “SAML is a compatibility minefield and requires constant tweaking” cost or a “we need to allocate some of our people to figure out the network setup together with yours” cost? Or something else entirely?

it's most likely "we couldn't be bothered to implement saml in-house or use one of the many existing libraries, so we punted it of to okta"

saml has annoyances, but it doesn't have so many annoyances that every customer needs to be a custom integration. the majority of users using saml are going to be coming from a handful of idps, typically adfs or google.

re: "we couldn't be bothered to implement saml in-house" This is NOT nearly as simple at that statement lays it out to be.

I am also from a SaaS vendor and we are using a 3rd party to integrate to the various SSO providers our customers have. We have not tacked on any additional cost to our customers for this as we also believe this to be baseline. But I do like the approach of at least covering costs.

For us it was not a matter of "not being bothered to implement saml in-house". We carefully considered our options. However, implementing it ourselves means we must have an in house expert on SAML and understanding the various IDPs.

It also requires someone to tightly monitoring any security issues that may appear in the wild that could impact our implementation. (We do still need to keep our eyes open, but we can leverage our vendor for help here.)

Resources required to this ourselves is a minimum of at least 1 full time engineer and someone who can be their backup, we need additional testing resources, and more. Making this roll < full time will hurt you down the road.

I'd rather our people can be focused on the problems our product is built to solve for our customers and then we can work with experts in the SSO space to guide / help us in solving that problem.

On the other hand: the 3rd party we're working with likes to come back every few months with a "Oh! We didn't know you were going to do (fill in the blank), we need to add another dollar per user per month for that."

Neither approach is perfect. But I lean towards keeping our teams as focused as possible on our product.

(PS: I have been with other orgs who've done SAML in house, and it is not simple. Don't underestimate it. It hurt, and we burned a lot of resources that could of been making our product better.)

Great approach. Wish there would be more vendors like that. This way we wouldn't even need to talk about SSO-Tax, availability of SCIM/SAML etc.

I'd rather consider it "SME pricing" vs "Enterprise pricing". Typically only companies above a certain size use SSO systems, and even larger ones require it for everything. Coincidentally bigger companies are also willing to pay more, so putting a high price on SSO enables SaaS to profit from those deep pockets without pricing themselves out of the market for smaller companies.

Things like Google Workspace et al. make it super easy to use SSO (ok a bit difficult but usable) even for smaller companies and honestly it should be used by basically everyone as a core security practice. It's annoying that companies charge out the rear end for a basic security feature. It'd be like charging to let people use 2FA/security keys.. just super stupid/arrogant.

> Typically only companies above a certain size use SSO systems, and even larger ones require it for everything.

I believe it's historically grown but it's not true anymore. More companies would use it if they could as this makes your processes way more automated, easier and more secure. Also more companies take security seriously (i.e. more and more companies get ISO27001/SOC2 compliant) but just can't afford the Enterprise prices.

That may have made sense 5-10 years ago. Todays expectations on security and convenience are very different.

Everybody deserves sso, regardless of size of company.

With the rise of micro services and DevOps, the number of applications used in an org has also exploded, adding even more reason to use SSO. Paying such big markup for every one of them is not sustainable for an SME.

Schools, colleges, and universities typically have SSO but no budget or purchase authority.

Just slap an education discount on it and call it a day. There are plenty of reasons to do that anyway, you want students to get trained on your software and use it in their formative years as much as possible.

Many go even further and just give the product away for free for educational institutions and individual students (Github, Jetbrains and Tableau come to mind as examples)

For a small-scale implementation in a university, open core without SSO is no-go: nobody has any money or purchase authority.

And of course part of why SMEs don't use it or don't use it everywhere is that suppliers make it much more expensive to do that because they insist security is only for Enterprise customers.

That means they can live without it. Enterprises can't so they pay for it. Making customers pay for what they need is reasonable. Sure, everybody would like to have every feature for free...

Of course small companies don't use it, because it is outrageously expensive.

SSO: Single Sign On

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.

SCIM: System for Cross-___domain Identity Management

System for Cross-___domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems.

SAML: Security Assertion Markup Language

Security Assertion Markup Language (SAML, pronounced SAM-el, /ˈsæməl/)[1] is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

https://en.wikipedia.org/wiki/Single_sign-on

https://en.wikipedia.org/wiki/System_for_Cross-domain_Identi...

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...

(if you work at SpaceX, SSO might also mean Single Stage to Orbit, which is lots more exciting - but since Elon banned acronyms maybe it's not used)

Thanks, I was wondering what "SSO tax" means. I see it differently. The enterprise plan is that the company really wants to sell. But it gives a discount to small companies that don't need the enterprise features like SSO, at least not from the beginning. I think it is very similar to freemium pricing - extra features, extra cost. Of course, when I look at a product, I look at all the plans and decide if it is worth the money now and in the future. I may feel pity and not buy it. But I never blame companies just for their pricing page.

Thanks for the useful link. The introduction says "like Google", but the table does not list Google pricing for SSO.

We use Google SSO at work, but I am just a user. Not involved either budgetwise or implementationwise.

I recommend some editing of the readme to clarify the tool's purpose. Initially I thought it might be an AI-generated spoof project since the description made no sense. I think the tool is for the following scenario: you are a manager in an organization where some set of your employees are using some specific SaaS (see list of currently supported SaaS'es below). You would like to see a list of the user accounts for your employees within your company's "___domain" in said SaaS, along with some account metadata. This tool extracts that info using the SaaS ___domain management API.

Oh thanks a lot. I updated the repo description. You're right with what you think though :-)

Laughs in enterprise pricing... 14 dollars a user a month? Try 250.

Last time I talked with dbt on their enterprise plan for the Okta integration level they pitched us 3000 user/year with the clear acknowledgement that they just raised their prices 100% on their other tier and were about to do major price increases to their enterprise tier.

If you work for a big company you need to play a little bad cop with companies like this. They usually only understand pain.

Have the sales team fly in and kick them out, etc. Try to get the highest level people possible engaged, then get unreasonable. All of these folks will report some crazy deal opportunity and their chief sales guy will be at their throats back at home. You’ll get the concession you need. Best advice is to just avoid suppliers like this.

SaaS companies know this too. They'll charge a higher price than they're actually looking to get because they know that if you provide a concession at every step of the chain of the customer (biz dev, salesperson, VP, CTO, CEO, etc) in the buying journey, you are more likely to be bought over a company who had a lower overall price but didn't provide concessions. There are people in procurement who literally exist only to extract concessions from the seller.

ya'all are talking non-sense.

someone used the word on my once i think. 'concession'. they made a 'concession' for me. don't think i twisted their arm or anything.

don't like these games these big players play.

I've seen this first hand in the pricing strategy of startups I worked with who were selling to enterprise. They might not use the word "concession" but they know what they're doing.

I'm sure, but marking things up so that some exec or purchasing agent can feel like they're "winning" when they talk that startup back down a few dollars.. it's ridiculous. Can we just do honest, transparent pricing? Please? :-(

No, because human psychology doesn't work with "honest, transparent pricing." People will go out of their way to buy things on sale even when the total cost is higher than it would be otherwise. JC Penney famously figured this out the hard way when they cut out all of their sales [0].

[0] https://www.priceintelligently.com/blog/j-c-penny-s-pricing-...

Yeah.... My take away is that people are dumb though. If you know this sales tactic then you should check the price history or competitor prices and only look at the final cost after fees, discounts and shenanigans.

> you should check the price history or competitor prices

That's why companies don't publish their pricing, to prevent something like this.

if it's online, someone is scraping it. and if it's not online....well, they're losing business.

I just laughed in their face and said that their product wasn't good enough for me to not just spend one week implementing the parts I cared about, and I did.

To twist rhe knife, tell them you'll publish the relevant parts as open source as well.

I have to say, I understood what this is really fast when I saw the README. It's really a great idea. I'dve been all over it before I :-) :-) retired.

It's going to save growing companies a fortune, by helping cancel promptly unused money-sucking accounts across the SaaS multiverses.

I just hope it's easy to use for superbusy founders, tech people now riding a success wave. Because those are often the people who do the account-cleanup job. If this tool is a pain in the *s to use, there's even more time down the hopper.

It's almost impossible for people like us to teach ourselves to delegate by inflicting pain on ourselves. And saving big money is worth some pain, amirite? Been there. Done that.

But HERE's an incentive to delegate:

* grab the most talented devops person you know. * tell them about this open-source project * delegate to them this account-cleanup PITA * invite them to donate time to the open-source project and give them time to do so. * but they still have to do the actual cleanup regularly. * stand back and watch the growth of a REALLY USABLE open source money-leak-hunting project.

Every single YCombinator portfolio company would benefit from this. You VC guys? Get some really smart interns to work on this too.

That's the spirit! Thanks for the kind words.

Indeed, ease of use is incredibly important. After all this is a tool that needs to be used non-developer IT admins as well.

I've done similar things in terraform in the past. But you eventually end up spending way too much time on it. If the tool isn't value enough for paying the premium, chances are there are other good alternatives, or we don't really need the tool to begin with. I just look at the individual plans as if they're student tickets for a conference.

Now lets talk about SaaS providers that don't offer any other way than paying by credit card. Not even pre-paying with a wire transfer. If you've ever tried to source a company credit card in a huge organization you know how hard that can be. And no way in hell I'm going to put $10k/month for various services on my personal credit card and expense it every month. It sometimes feel like they don't even want to run a business.

The SSO part is a bit confusing since it sounds like the product is letting you download account and permissions data based on your own api key. It might be helpful if you clarify how you can help with the SSO portion of things.

In a similar vein, I’m confused by the messaging: “SSO is expensive” problem, the “access user data” problem, “centrally manage permissions” problem, and “automatic account provisioning/deprovisioning” problem.

The marketing seems to jumble those 4 problems into 1 problem when (at least to me) they’re 4 very distinct problems to solve.

That leaves me wondering which of those problems are you truly solving? All 4 or just a subset?

Fantastic feedback. Indeed these are distinctive problems. For instance, "SSO is expensive" seems to be the root cause for the "centrally manage permissions" and "automatic account provisioning/deprovisioning" problems. At least when we're not talking about enterprises.

OpenOwl tries to give transparency over the user permission data in your SaaS tools - independent whether you have SCIM APIs or not. It's read-only though. No automatic account provisioning here.

However, as some of these problems are very close to each other, it could make sense to solve them together. But that's not the intent for OpenOwl.

That's a good point. Indeed there is a technical focus on login flows at the moment as this seems like the hardest problem to solve. Adding API key flows makes definitely sense though!

I really want to like this but the limitations described, requiring an admin account with 2FA disabled, makes this more risky than not using it at all.

Until those limitations are resolved, if that’s even possible, this feels like an audit hack rather than a security solution.

In future versions it will be possible to do the same with, for example, your Google SSO sign-in and 2FA enabled. The reason for the limitation is that we simply wanted to get it out into the world and see if anybody is as excited about it as we are.

For reference, the azure client, opens a browser for the login, which redirects to a dns address that equates to "localhost" on a port that will effectively get the final auth tokens to the local instance, which then persists and shuts down the service. Should be able to do very similar.

Yeah, the current approach basically makes this entirely a non-starter for the target audience (eliminate a critical control for people for whom critical controls are a pain point).

Uploading your 2FA tokens to a third party is also likely a non-starter, sorry.

You don't need to upload your 2FA tokens somewhere. Everything runs on your local machine. You can do whatever you want there.

Have you looked at Cerby?

Shameless self-plug for an alternative tax that affects operational security and reliability teams: https://audit-logs.tax

Understanding how your breach impacts me, or detecting how the abuse of your tools are used to impact our organizations shouldn't cost additional money or be gated to only enterprise contracts.

Happy to take PRs for other vendors logs being added: https://github.com/shellcromancer/audit-log-wall-of-shame

As one who self-hosts a number of Open Source applications for a small group of family and friends, I would love to have a simple SSO proxy solution. Many "open core" applications don't include SSO in their Open Source offerings, thus locking small non-commercial users like me out of SSO features for my small non-commercial group.

I don't really need all of the auditing and compliance features this solution seems to currently offer- I just need a simple SSO proxy. If some one wants to build that, it could be a huge help for small non-commercial self-hosters like me.

We have built one. Our service is free for up to 25 users. Just head over to https://datawiza.com to check it out. Hope it helps you and your friends & family enjoy your self-hosted apps even more!

You should check out cloudflare access. It let's you put single cloudflare login in front of all the other self hosted apps.

I used Authelia and use OIDC wherever I can.

Thanks, I haven't heard of Authelia before, looks like it may work well for my use. I see the OIDC provider support is considered beta, have you had good luck with it being stable and reliable?

Yea have been running since it came out.

What's important is that you follow the releases. Read the logs after you update. Something the configuration format changes.

And there are some rough edges. But those are OIDC related. The actual authentication part is much older and stable.

I've only had issues with a configuration NOT allowing me to sign in. Which I appreciate. I rather have a bug that blocks me vs one that allows me.

And they're pretty responsive on discord.

https://github.com/doncicuto/glim :

> Glim is a simple identity access management system that speaks some LDAP and has a REST API to manage users and groups

"Proxy LDAP to limit scope of access #60" https://github.com/doncicuto/glim/issues/60

I think your positioning is wrong. The problem this solves is auditing user accounts in SaaS applications. That is a great problem to be solving, and you can position yourself on that! Why talk about 'SSO Tax' when this has nothing to do with SSO?

There is at least one other 'open' library for solving this problem (https://github.com/ConductorOne/baton).

However, I like how you're scraping web data for apps that don't have APIs. I've been waiting for someone to do that. That said, I want it built into other tooling I have purchased, so I don't have to implement myself.

'Auditing user accounts in SaaS applications' is a pretty good summary of what the current version is about. The 'SSO-Tax' has become a synonym for the extra charges of SaaS vendors in which they usually bundle 3rd party SSO, SCIM and SAML.

What other tooling would you want it to integrate with?

Cerby does this. I'm not them, but I know one of the guys there.

This is cool, in that it might encourage SaaS providers to reduce the SSO tax. Discouraging security affects all of us whose data is held by other companies (ie everybody). I'm sure you'll get comments that you're being penny wise pound foolish and wasting your time with these hacks. That entirely depends on where your company is located.

As it supports so few services, putting the list up top in the README would be a good idea, and a quick explanation of what programming languages/methods can be used to add more services. The chances another organisation has picked the same 7 services as you is pretty low.

I really hope that companies stop putting SSO/SCIM into a separate plan but allow using it in lower plans.

Thanks for the idea. That makes sense. We hope that more recipes can be added soon so that there is more coverage for everyone.

I think this is an amazing idea! I am struggling with a similar situation now.

Anything that will allow to semi-automate this, and get a periodic report that compares this to where the Single Point of Truth for the account list would be amazing.

Great to see that we were not alone with the struggles! Let me know if you are up for a quick chat. Would love to learn more about your situation and how OpenOwl could help fix it. If you are up for it, my contact is in the bio

It'd like some kind of chrome extension that will 'sso-ize' any 3rd party web app.

Ie. it will create a temporary [email protected] email address, use that to sign up to the 3rd party web app and keep the password secret from the user.

Then, when the user returns to the site, your on-site server provides the auth details for each logon (or even better, logs in for the user and just sets the right cookies).

For some sites, it will also make sure the user is a member of the right 'team', has access to the right shared documents, has their display name matching their name in the corp database, etc.

Google Workspace can (sort of) do this. Although after googling, looks like they’re removing support.

Basically it allowed IT Admins to “hide” the password from users logging into websites with traditional user/pass login flows.

https://support.google.com/a/answer/9178974?hl=en

A fintech that can't pay $14 per user? How many employees do you have? "hours per quarter" but it's not worth the money? Where's the problem? Either you spend the money on a few hours of work for an intern or you fork over SSO money.

SSO isn't a tax. You either need a single method to disable an account across all providers instantly and enforce password policies globally, or you don't. Do the risk vs reward math and then put the line item in your budget. Get a discount or use a reseller to avoid retail.

It'll be that price multiplied by how many SaaS tools you use, each of which will have some premium for their Enterprise plan supporting SSO, and typically they won't be transparent about what the price is or how to sign up for it, so you'll then have to go through the steps of negotiating an enterprise plan. Spending a few minutes to figure out their API sounds more fun

Why do you need all of these tools?

It’s really a cost/time to market comparison between the SaaS and you just using SharePoint or managing some substitute. If you’re proposing to drop $80 u/m for Airtable, there better be a tight business case.

I would argue that any company with 3 or more employees needs an SSO.

Back in the day SAML was the only game in town, SSO was an enterprise feature. Nowadays with oAuth/OIDC, this is a no brainer and you can get a basic setup going with plain Google Workplace (Gsuite/Gapps/...) without the need for anything else.

Yet SSO keeps being bundled in the premium feature list of most of the SaaS products out there, costing 10x to 100x more per user.

14$ sounds pity, but when you take it in the equation of "price per slot * total slots * products * 12 months", you can get to some serious numbers even for a small 10 people company.

Notice I said "slots". That's because the nasty trick lots of SaaS do nowadays to boost their profits. They will auto provision a slot when a new user onboards, but when that user account gets removed (with or without SSO), they will keep charging you for the slot until an admin goes and reduces the slot amount by 1. This is something that AccessOWL can help with, I suppose.

Indeed, that became a bad practice... Zoom, Calendly just to name a few do that. That's so stupid and just not customer-friendly at all. Whenever I see this, I start searching for an alternative... But there are also role models in the market like Slack that prorate even based on days after a user was deactivated. And they even remove users from billing when there were inactive for a longer period. Very kind :-)

If it's one tool, it's not a problem. If it's every tool, it becomes a problem quickly. I had a tool that moved from 300/month to 2,000 a month just for SSO (for our needs.) Launchdarkly is just not usable due to the additional price for SSO.

It's absolutely a tax if it's the only feature you need.

> A fintech that can't pay $14 per user?

There costs add up quickly and it is prohibitive for a small business that is not profitable.

As someone who has worked with SAML and other authn/authz technologies, I can only say that the reason for the SSO tax is because that stuff is unreasonably complicated and hard to make work. From things like Microsoft's half-baked proprietary version of SAML to the typical company's crappy in-house login system that was thrown together on top of a system built with security as an afterthought, doing SSO is never simple. Security as an afterthought is always way more difficult than if someone had thought about user roles and permission from the beginning. On top of that, even little companies expect to have things like "well, the execs never really log in, so we need to be able to delegate permissions, but only for things the execs want them to do. We can't give them permissions to sign off on bonuses for themselves".

Knowing what I know, I don't really begrudge any SSO provider their premium pricing.

I think using the term "Skip the SSO Tax.." has done a little disservice to you, and I understand why you chose that term, but this is more "Skip the SCIM tax" I think?

Regardless, I totally understand the use case and I can immediately put this to work for my team - we will likely contribute some recipes too.

Thanks for sharing!

That's what we try to simplify at Resmo. We integrate with 80+ most popular tools a company might be using. Of course there are some we don't cover yet. Only 3 tools requires paid-tier for API access. Also, we list access Login with Google data from your workspace. We gave a central place for you to list the users and their permissions.

https://resmo.com/saas-discovery

Then you can do `SELECT * FROM users WHERE mail = '[email protected]'`

“The SSO tax” is the unofficial name for the practice of software vendors significantly upcharging their customers for Single Sign-On.

(No, it's not Social Security Organization tax...)

As a dev who primarily uses Elixir, I was excited to see that you built OpenOwl with it!

Out of curiosity, what made you choose Elixir?

I wanted to use Elixir to build my PDF scraper (https://github.com/Nezteb/scrape-pdf) but didn't want to spend too much time figuring out how to use Playwright from Elixir, so I went with Node. I'll have to borrow some of your methods!

Oh yeah, Elixir is just amazing <3. We use it for our commercial platform accessowl.io. Parts of OpenOwl are originated from there. It was the fastest way to push OpenOwl out. Moreover doing it like this allows us to use OpenOwl as library there.

But yeah I was thinking longer about it as Playwright is pretty good for scraping/RPA and works best with Node. One (expected) limitation is that we cannot easily open a browser window to let the user enter a OTP or solve a captcha as we encapsulated everything into Docker. Not sure how we can solve it yet...

the "SSO tax" is literally the entire SSO product, a solution to a legitimate problem that businesses face and gladly shell out $$$ to not deal with. if your suggestion is to not pay said $$$ and instead roll your own solution, more power to you, but you're not "skipping" the SSO tax, you're simply passing it onto a different team to do the work of what SSO would provide you.

To be fair - if the SSO tax was just a single SKU for adding _just_ SSO to the platform and it was a reasonable like $2 - $4 a user addition, most people wouldn't care. When we refer to the SSO tax what we normally mean is that SSO is gated into the "Enterprise" category of a tool for some reason, implying that only Enterprises use SSO. The difference usually also includes other tools that the customer doesn't need (we only want SSO) and so the price difference is usually huge. It makes SSO unrealistic for non-enterprise size customers.

IMO thats generally what people refer to when they say SSO tax. It isnt discounting that providing SSO requires work, its that its never decoupled from a huge platform upsell.

This reflects a trend of smaller and smaller companies using SSO, including startups that now use SSO right from the beginning because they know that certifications like SOC2 are on their roadmap and they want to get best practices in place early. In the past, it really was a 99% chance that customers wanting SSO were large companies, but that is changing.

That said, I'd say the trend is overrepresented in places like HN. It's still mostly bigger companies that want SSO, which is why SAAS cos keep using it as a pricing differentiator.

Why don't companies instead of doing this simply say "if you have more than X employees you can only pick the enterprise tier"? Is it illegal or something?

I mean you could of course lie when signing up but if a company is risk averse enough to use SSO it's probably risk averse enough to not breach contracts.

Because it's hard to formulate a subjective choice of X, for starters.

Can anyone think of any other reasonable product-agnostic criteria other than SSO?

This reads like a something written from the perspective of somebody involved in the creation of a SaaS product, but that has never actually been involved in buying one.

To summarise your comment, my notes in parentheses:

* This isn’t as good as SSO (I’m sure that OP knows that).

* It doesn’t meet your requirements (I trust OP to know what their requirements are, and I myself have been in situations where this would be useful).

* Implementing SSO from scratch isn’t hard. (That doesn’t mean bupkis to someone that wants to use SSO functionality of a SaaS product that they are subscribed to. Also, I’m highly skeptical of any SSO implementation that was ‘easy’ to write).

* SSO’s usefulness is limited without proper access controls within the product (…yes?)

* Only ‘enterprise’ customers want/need SSO. (This is a clear example of uninspired SaaS companies drooling over the white elephant ‘enterprise’ customer: someone with a bunch of money, that will pay for your value-add crap without batting an eyelid. I’ve worked in plenty of settings that I wouldn’t call “enterprise”, but that would’ve benefited highly from SSO. Unfortunately SSO is always locked behind AT BEST a significantly higher seat cost, but usually with a very high floor, and often behind a “contact sales” funnel. Replace “enterprise” with “business”, because that’s the reality. Then…look at your (probably B2B) SaaS product’s package differentiations, and tell me that you aren’t screwing people).

* Enterprise plans usually come with way more than just SSO (Yes! half the point is that most people don’t want this stuff! It’s mostly shovelware to make it not look so egregious to pay so much more for SSO! You’re right! SSO is a small part of that! So why force people to buy the rest of the stuff if they don’t want it? Oh, that’s right, because you’re lining up behind the other SaaS vampires to prey on basically any organisation of more than 5 people that wants have their ducks in a row).

It really just sounds like you’re trying to justify your employer’s crappy yet common sales tactics, and we’re just coming along for the ride.

Hey, could you please edit out the swipes in your comments? You've got some great points here and you obviously know what you're talking about, but the first bit and last bit really acidify what you're saying.

(To be clear: I'm not talking about the "SaaS vampires" bit - it's colorful language that's not targeting anyone in particular; it's flamebait, but not so bad that we'd post a scolding. It's the personal swipes in the first and last sentences that are the problem.)

If you could make your substantive points within the site guidelines, that would be the sweet spot. They're here: https://news.ycombinator.com/newsguidelines.html.

I'm my own employer, and I'm usually way more passionate about writing features in my problem ___domain than implementing SSO & other enterprise features, which BTW are not in any way a differentiator or usable as a sales tactic. It's just that without SSO you won't be able to sell any enterprise software anymore, at least if it's a web-based product. SSO isn't something that SaaS startups try to push on enterprises, it's rather the inverse.

Our customers, which are often regular people working for BigCo that try to solve their own work problems aren't overly fond of SSO either, they just need to implement it as a policy since most companies enforce it from the top. You can debate whether that makes sense but if you're running an organization with tens of thousands of employees then not having a unified authorization & access control solution in place is regarded a bad practice, and for very good reasons. SSO solves many real problems that were extremely painful before, where you'd have either no common authorization at all or would need to write LDAP integrations. For all the flak it gets, SSO is orders of magnitude easier to implement and better at enforcing security best practices.

And the reason most SaaS vendors don't put price tags on their website is that it's extremely hard to do pricing as software integration in most enterprise environments still requires a ton of consulting and bespoke development, so if you e.g. put a 10.000 USD price tag on that you're setting yourself up for failure as you typically won't be able to estimate the integration cost until you've talked to the customer and assessed their needs and their IT environment. Deployments have become better as tools like Docker and Kubernetes become more ubiquituous, but it will still take many months to years in most places.

And writing an SSO implementation isn't difficult thanks to many libraries that are available and that do the heavy lifting. In the end SAML-based SSO isn't much more than reading a metadata document, forwarding a user to an external URL, parsing the response document and verifying its signature and generating a local access token for the user. The complexity lies somewhere else, e.g. in the role mapping and in working around the quirks of the specific SSO environment you encounter. Customers e.g. love to use non-standard fields to map organizations, users will often have inconsistent role and organization mappings, the customer wants to add some additional metadata field etc. etc. etc...

> It really just sounds like you’re trying to justify your employer’s crappy yet common sales tactics, and we’re just coming along for the ride.

That's your perspective, but let me try another one: So many SaaS products have a free/low-cost tier that allows people to get basic functionality for nothing or extremely cheaply. Users are clearly not unhappy with this and the vendor gets market share and awareness.

However, there is still a cost - and that cost ends up getting subsidised by commercial customers that have a hard need on a small number of features.

That, and the fact that even 'small' business customers these days make you fill out the same 'security review' forms that they don't understand and never read, can require a lot of hand-holding (especially if they have a procurement or legal person who wants to get their requirements in) and can take forever to do a Proof-of-Concept.

ALL of those things have costs and guess what, they end up being added to those small number of 'must have' features.

That is why a base tier might be free but suddenly you add something like SSO and the cost doubles...

> SSO is just a handy feature that non-Enterprise customers usually don't need while Enterprise customers do

This isn’t true, IMO, most people just don’t realize there’s an alternative to one user account per service. We’ve convinced non-enterprise users to use an objectively bad solution of password managers because every SaaS service hides their SSO option behind enterprise pricing.

Eh, practically every service will let you 'log in with google' (or equivalent) for free if you're the sort of user who prefers that to a password manager.

SaaS companies want to charge a lower price to price-sensitive customers like bootstrapping startups, and a higher price to price-insensitive customers like big corporations; and they need some way to draw the line. And the moment you've got time to waste on things like SOC2 that drive you towards SSO - you are a price-insensitive organisation.

It’s sort of funny to me that if you go back to the timeshare computer systems of the 70s, everyone took for granted that you logged into the “network” and then the access you had depended on the permissions your user had. Today, we log into our computers and then we spend lots of time every day juggling credentials for the third party services we use. And, to make it worse, companies expect you to use various SaaS apps for day-to-day life and then block (or the apps just don’t provide) all the means to automate repetitive tasks.

Oh yeah, that's indeed a step back when you compare it like this. Especially today, automation should be possible everywhere. There is no real reason for that. SaaS apps could just stop blocking that and everyone would be happy. Some just need to start...

"Login with X" is terrible because you don't much of a choice for X. Google is generally there but maybe I don't trust Google as a gatekeeper for everything I do on the Internet. I certainly don't trust Facebook, which tends to be the #2 spot for the "Login with X" option.

> as most security certifications require SSO as a best practice, manually syncing users from different tools won't cut it

Having taken a couple companies through SOC2, I can say that's not true.

Lots of apps being used by enterprises don't even have support for SSO at all, even if you were willing to pay the tax. Audits can't require you to use something that does not exist. Thus, the manual syncing and comparing is a frequent ritual of audit compliance (and to be fair, is something that should be done regularly even if no auditor is asking for it).

> Also, implementing SAML-based SSO from scratch isn't that difficult, I did it for our enterprise product and it's barely 500 lines of code.

That's not the problem though, the issue is third party apps that don't want/care to support SSO. You can't go and modify their code.

Hey mathiasn, I totally feel your pain! I work with the same kind of solution and know how everything can get way more complex than people think, I really liked the "recipes" idea for integrations. If you don't mind how about we have a chat?

Sure, feel free to raise a GitHub issue, happy to discuss.

Sorry i wasn't clear, I mean talk about the company/career, I worked developing IAM for the last 4/5 years and I am looking around for new opportunities.

I like the fact that one could use this within a CI/CD pipeline for example.

Well done, thanks for sharing!

The SSO tax exists because it's historically been a roundabout way of segmenting the market into businesses vs. individuals and charging businesses more.

If you all think your vendor’s SSO price tags are bad, you should stay far away from what their healthcare HIPAA prices are.

Love this idea - was considering trying to build something similar recently.

Thanks! Happy to chat if you want to share some of the ideas you had

Did you also consider building it with Elixir and LiveView?