[smitty1e]

> Single sign-on (SSO) is a mechanism for outsourcing the authentication for your website (or other product) to a third party identity provider, such as Google, Azure AD, Okta, PingFederate, etc.

OK, so SSO==OAuth.

What TFA doesn't mention is that we're enabling surveillance capitalism by SSO.

"Who owns the customers" might well be an SMB consideration.

[scott_w]

Agreed, they’re conflating things like Google Sign-in with enterprise offerings like SAML. Companies generally give away Google Sign-in for “free” as it’s a great growth vector and gives SMEs a sort-of SAML setup for low cost. It’s also really easy for the vendor to support: you just click the button and you’re in.

Granted, it lacks some of the benefits of SAML, such as permissions assignment from a central source. But this is also why those features are so pricey: enterprise organisations derive the most benefit from it, and have a team dedicated to its maintenance.

[ArchOversight]

They aren't conflating anything. OIDC or SAML should not be "taxed" extra.

I do work for a number of small businesses and they can't afford the "enterprise cost" for things, so there is a shared password vault instead because there is no centralized management of users.

The small businesses all have some form of SSO available, whether they are using Azure Entra ID or Google Workspaces, they have a central location for users, but the cost is prohibitive for most products to get the upgrade to get access to SAML or OIDC for SSO.

[lelanthran]

> OIDC or SAML should not be "taxed" extra.

But it costs extra. That cost is passed on to the consumer.

The major hurdle is that it's expensive!

Take a typical small business SaaS - providing SSO instead of standard passwords can take more time and effort to purchase or develop and to roll out than the actual SaaS software.

Okay, lets say you buy SSO: offloading to a service is going to cost a minimum of an extra $20/month/user.

Building it? That's going to take months of developer time, not to mention that this is a high-touch/high-feedback feature, which is going to eat up the service employees time.

And then the rollout, which almost always needs a month of external consultants getting everything working correctly.

I'm doing a small SaaS, $15/user/month; if anyone has any good recommendations that aren't going to to cost me a quarter of my current sale price, I'm all ears.

Even if it's DIY, as long as I don't burn a month of dev-time just for integration/deployment.

[ArchOversight]

There likely is an off the shelf OIDC SP provider you can use for the actual "hard parts".

If you already use something like "Sign in with {Google,Facebook,Twitter,Apple}" you are already doing part of it.

I have built several products now with OIDC support for authentication (not authorization) and it has never taken more than a day or two to wire it up.

[scott_w]

My advice would be to wait until a big enough customer is willing to pay through the nose for it. You’re “lucky” in that you charge per user so it’s easy to model into your pricing :)

[scott_w]

I address this here https://news.ycombinator.com/item?id=40752797

[scott_w]

To be clear, SMBs should be allowed to use Google Sign-in or Azure’s equivalent for the base pricing. I think this is table stakes for features (and security).

SAML? No chance. SMEs don’t need it and my comments above explain why vendors will never offer it.

[ArchOversight]

Google Sign-In is locking people to using Google's infrastructure. If an SMB has already deployed using Azure you don't get access using SSO, instead you have to fall back to username/password?

Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.

[lelanthran]

> Adding support for OIDC is not that difficult. I prefer OIDC over SAML anyway, but neither is that difficult.

Since it seems that you know what you are doing (and you've done it before), how about a blog post detailing the steps one would go through when writing some SaaS app for a client who wants SSO?

[scott_w]

If it requires configuration on the user’s end then it’s no better than SAML from the vendor's perspective. We’d much rather choose specific providers to hook into, based on the likelihood of increasing sign-ups.

[ArchOversight]

The SMB is the customer, they should already have a single place for all their users and for authentication.

SSO doesn't have to be Google, Azure, Okta, PingFederate, you can run a stand-alone instance of Keycloak for instance and have OIDC and SAML available to provide SSO functionality.

[smitty1e]

Probably more the M than the S in SMB.

I'm fond of saying "Everything is easy, when you know how to do it", but getting these security details absolutely right isn't entry-level.