Not to defend this practice, but SSO does tend to produce an additional support burden. It's complex, there are many knobs to fiddle with and it can be tedious to figure out if the customer (via configuration, or their identity provider itself) or the vendor are at fault for an issue.

Just had an issue today, I'm reasonably sure it's the customer's fault. But I also misread the spec earlier and was wrong about some parts that worked out of the box with one identity provider, but not another one. So who knows. Okay, I assume this parts gets better once your SSO implementation gets older, but it's a pain when you're starting out with it.

▲

stackskipton 2 days ago | parent | next [-]

Yep, I used to deal with this at $LastJob and amount of support burden was terrible.

Azure AD/Entra ID (Microsoft IDP) was most common and amount of IT folks who don't have a clue about it is staggering.

Companies kicking over issues to us when it's their problem. "Hey, we have a ticket saying MFA Required but account shows as Entra ID." "Send it back with contact their IT team." "Their IT team opened the ticket" rage screaming

Companies not following setup instructions. I used to provide Terraform, Powershell and Graphical setup. I can count on one hand how many people used Terraform/Powershell. This was always dicey because I got familiar with the error messages and would be "Yep, this was not setup right on their end." I had 4 phone calls with $CustomerIT swearing it was setup properly and stopped attending after that. Finally they got someone with a brain to review and finished setup.

Documentation would fall out of date because of some UI change and I'd spend a day reviewing it and updating it.

▲

mikestorrent 2 days ago | parent | next [-]

To be fair, Entra is an abysmally bad user experience; their support barely knows anything about it. Provisioning is clunky and slow. Applications are split into two halves. Self-service password reset is a half-finished joke.

Tip of the iceberg: adding a custom field to a user record is possible, but you need to use the Graph API to do it; once you've added it, it is never visible on any UI, you can only get the data back out via API. So good luck making a custom field that your clerical staff can actually work with.

There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.

▲

stackskipton 2 days ago | parent [-]

>There's Terraform support to add applications to it, but you end up having to go in and click "grant admin consent"... no way to do the whole thing IaC without a bit of manual interaction. Maybe that's a good thing? Annoying anyway.

Previous customer IT support staff, is that you? I kid.

resource "azuread_service_principal_delegated_permission_grant" "grant" { service_principal_object_id = blah resource_service_principal_object_id = blah claim_values = ["openid"] }

	▲	mikestorrent 2 days ago \| parent \| next [-]
		Hmm, I could swear this didn't work the last time I tried it, but that was a while ago, and it worked an absolute treat. I was probably just confused by it. Thanks for the pointer, you've made things a tiny bit better :)
	▲	2 days ago \| parent \| prev [-]
		[deleted]

▲

lurking_swe 2 days ago | parent | prev [-]

I’m confused.

_allowing_ a user to configure SSO for free doesn’t require a company to offer onboarding / education help to that user. That can be offered exclusively to paying customers.

▲

crinkly 2 days ago | parent [-]

I will say that most of the consumers of SaaS SSO solutions in our experience are the lowest bidding MSPs the customer can find or some oursourced operation. They usually employ the lowest paid fuckwits who play pass the blame around as long as possible and expect the supplier to prove every issue isn’t them.

Of course we’re happy to charge them to deal with that shit.

If we don’t then they go to twitter and the trade press to shit on our product.

	▲	lurking_swe 2 days ago \| parent [-]
		i do sympathize - dealing with customers can be a nightmare sometimes.

▲

grinich 2 days ago | parent | prev | next [-]

I started a startup to fix this exact problem integrating and configuring SSO/SAML.[0]

We launched here on HN 5 years ago[1] and today power SSO for OpenAI, Cursor, Vercel, and a thousand other apps. We also found the initial configuration step to be painful for users, so we built a self-serve wizard that enables enterprise admins to fix issues.[2]

It's still crazy how much complexity there is with enterprise identity systems and managing the user lifecycle for big orgs. It's like the whole thing is made of weird edge cases and even moreso when you add SCIM, RBAC, MFA, etc etc.

(If anyone reading this also loves suffering at the intersection of IAM and developer tools, we are hiring! Email in my profile :))

[0] https://workos.com

[1] https://news.ycombinator.com/item?id=22607402

[2] https://workos.com/admin-portal

▲

grinich 2 days ago | parent | next [-]

also if anyone wants to go down the rabbit hole about why SAML is hard to implement, this is a pretty interesting writeup of a major 0-day vuln we discovered earlier this year: https://workos.com/blog/samlstorm

▲

bks 2 days ago | parent | prev [-]

Happy workos customer for at least 4 years. Thank you.

	▲	grinich 2 days ago \| parent [-]
		thank you! feedback very welcome if you have any suggestions for things to improve or ideas for what we should build next

▲

NegativeLatency 2 days ago | parent | prev | next [-]

Especially so if the customer is not a tech company or otherwise has IT staff that aren't uh motivated.

Add in SCIM and IT people "changing stuff to better align with our other stuff" and you just get a whole steamy barrel of fun.

	▲	mikestorrent 2 days ago \| parent [-]
		God forbid the evil IT department just wants you to have the same username everywhere

▲

9dev 2 days ago | parent | prev | next [-]

Are you working for Stripe and the issue is names not syncing via SCIM perchance? In that case I’m the customer and reasonably sure it’s your fault ;)

	▲	fabian2k 2 days ago \| parent [-]
		No, it's far, far smaller and very specialized software.

▲

EE84M3i 2 days ago | parent | prev | next [-]

Is there a go-to vendor/library that handles this (OIDC, SAML, SCIM) for SaaS services these days? Just like how everyone uses stripe for billing, everyone uses <vendor> for auth?

	▲	grinich 2 days ago \| parent [-]
		(self plug since you asked!) WorkOS does exactly this. It's "Stripe for enterprise features." https://workos.com Our customers include OpenAI, Anthropic, xAI, Cursor, Perplexity, Vercel, Replit, Webflow, Clay, Hex, Carta, Plaid, Drata, Vanta, and many others. If you've used these products, you've used WorkOS! WorkOS makes it easy to "cross the enterprise chasm." Here's a bit more of the backstory: https://x.com/grinich/status/1841569664465568248 We also launched on HN 5 years ago :) https://news.ycombinator.com/item?id=22607402

▲

jelambs 2 days ago | parent | prev [-]

My hot take is that the SSO tax is totally legitimate because SSO is a clunky and complex feature to manage in a secure way. In fact many SSO implementations are actually not that secure because SAML is a dumpster fire when it comes to security vulnerabilities.

Most companies can get equivalent security and a better overall experience just using Google OAuth. The argument that you're having to pay for security features that should be available to everyone just doesn't compute for me if you offer Google/Microsoft OAuth, which most smaller companies are going to be using instead of Okta/etc to begin with.

If you really need SSO, it's probably because you're trying to manage massive amounts of user and do SCIM provisioning, etc. In which case, there probably will be some burden on the vendor to make sure that this all works smoothly or they'll pay a vendor (like us, I am biased as one of the Stytch founders).

We built an open source library, SAML Shield [1], to help companies secure their SAML implementations. And while hopefully this helps reduce the burden for teams maintaining in house SAML, the reality is that it definitely is a burden.

[1] https://samlshield.com/