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.
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.
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.
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.
Previous customer IT support staff, is that you?
resource "azuread_service_principal_delegated_permission_grant" "grant" { service_principal_object_id = blah resource_service_principal_object_id = blah claim_values = ["openid"] }
But we should also draw a distinction between, like, real security defects (RCEs, that sort of thing) and features that might make it easier to deploy a system securely (SSO).
I really appreciate Cloudflare not putting SSO behind a paid subscription because using their Cloudflare Access product with Github SSO has been the easiest way to secure my personal services running on a VM.
heya robertkoss, FusionAuth is software you can run yourself for free which is comparable to Auth0, Clerk, WorkOS. We have a community plan with unlimited SSO providers (SAML and OIDC; sorry, we don't support WS-Fed).
Here's the doc to set up an OIDC provider to Entra ID: https://fusionauth.io/docs/lifecycle/authenticate-users/iden...
We have other things we charge for (pricing here: https://fusionauth.io/pricing?step=plan ) but we don't charge per SSO connection.
I recall early in my career, I was building out a pilot version of a service. Early feedback was that users loved it, and it looked like the tool would be a good way to build our brand, but not a huge money maker. Cost per seat would be about $15/mo and we expected to sell less than 10 seats per customer. SSO integration would be a flat one-time fee in the mid four figures, and my boss laughed when he explained there was more money to be made integrating a mediocre service than selling a perfect solution behind a traditional username and password login.
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
Previously, on this, from me:
The fallacy is thinking that the alternative is for everyone to pay the lower price and get the enterprise features.
In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
You can call it an SSO tax, but it would be equally correct to refer to the lower price as the non-corporate discount.
The reality is you can't just carve out on feature and say "we pay for this." I mean that's true of a lot of things. The big revenue generators pay for a lot of things, but how things are billed is important. Remember, not to long ago people paid for Netscape, but now its laughable to pay for a browser. Its arbitrary to have this 'buffet' mentality and seems purposely shaming towards people who rightfully complain about ridiculous pricing structures like this.
I'm also skeptical that SSO costs vendors money. Maintaining and supporting an authentication database is a huge expense. For every SSO client, its one less Adobe or whatever account that needs to be hosted. Less helpdesk tickets about password resets, etc. SSO tends to be once and done. Hosting millions of accounts and being the sign-on provider for them is not 'once and done.'
Lastly, a lot of orgs don't do this. A lot arent SOC2. That means they'll just use whatever account the vendor supplies, and most likely without MFA, but their SSO would have provided that, thus making everyone more vulnerable. This is a great example of how exec salaries and stock buybacks and other things have priority over security because security is seen as a cost-center and without litigation or law, stuff like this becomes the norm. Oh and now there's one more source of passwords out there and another potential hack.
This is just greed and predatory. Its not the wonderful largess of big companies. It fact, its quite the opposite.
> The right way to think of the "SSO tax" (where companies charge extra for security features) is "You are being offered a dual use product backed by a strong engineering team for far less than it would otherwise cost, with sophisticated enterprises picking up the slack."
That said, TLS/SSL used to be the preserve of the enterprise too (or at least the ecommerce site).
There are lots of free options, including 3rd party servers and libraries. I'm hoping eventually SSO will be, if not in free versions, at least not isolated to enterprise plans.
Or the IdP is administered by the enterprise's own IT operation.
The outsourcing of your security to (and also consequently leaking information to) a third party IdP is a fairly new phenomenon in 'security'.
Someone must have paid a lot of money to promote that idea.
The way I typically look to segment and price things is by billing based on organizational complexity rather than gating end-user features whenever possible. If something is a specific need for a large org, it should be a higher tier, since those organizations typically have a larger ability to pay. If it's something that a single seat user would want if they were an expert, I'd rather not tier on that - it basically would be shitting on your largest segment of superusers / fans / influencers for most B2C apps.
Put a different way, if I were subscribing to MS Paint, I'd rather have to pay more for SAML/SCIM provisioning than to pay for the number of particles the spray paint tool can output at once. One limits orgs, the other limits users. You should never limit users without reason.
SSO was by far our most expensive feature to support. It was the single largest bucket of support requests and a significant percentage of those requests required an engineer to get on a call with a customer (and their IT team).
We evaluated building better product/tooling to self-serve, but we realized that it likely wouldn’t solve the issue. SSO is security critical, so anytime things go wrong people throw their hands up and say “nope, I’m not the one that’s going to hurt my company”. They really just needed someone on our end to give them confidence.
Don’t get me wrong, we fixed many of the biggest issues - but there’s an endless supply of crap that can go wrong.
I can confirm this is how it goes.
You can theorize about how SSO should be straightforward or self-serve, but in practice the SSO feature creates a disproportionately large support and engineering burden.
When you’re dealing with SSO support for a customer buying 100 expensive seats it can be easy to justify.
When you’re debugging the SSO for some small shop with 3 licenses who will churn suddenly the moment their lead noticed a shiny new competitor, it’s not worth it.
Every time someone has a problem create docs for it and after some time those questions will reduce significantly.
edit: also, for people implementing this the first time it should be obvious what happens when
1) they create a new account in your app (local)
2) if they create a new account within SSO provider
3) what happens with existing accounts during setup and if current users will be migrated over or not (or if they can use both singins)
And customers don't necessarily read the docs, or even if they do they don't configure everything correctly.
baq•53m ago
if you need SSO but you don’t have money, you have issues
mungoman2•50m ago
baq•42m ago
tptacek•32m ago
mmerickel•42m ago
datadrivenangel•28m ago
simplyinfinity•40m ago
rawfan•33m ago
NewJazz•28m ago