The era for security and in particular identity and auth management to be pay-to-play is long over and I appreciate when projects and businesses are honest about that.
The era for security and in particular identity and auth management to be pay-to-play is long over and I appreciate when projects and businesses are honest about that.
You seem to be advocating for SSO for personal use too, to which I say: hell no. I don't even use the same email address between different sites. Why should I give every site I log in to a freebie for cross-site tracking?
I was speaking primarily from a business perspective, in particular one where I make technical decisions for mine and other (client) businesses.
Experience has taught me that SMBs benefit greatly from SSO. They’re also simply the least likely to have the talent around to implement it well and reliably. So while you can use the SSO tax to drive revenue, you’re just moving the burden of account management to individual users and admins of small teams. As a long-time provider to small teams I can tell you how much they really hate dealing with that overhead when they probably already have a SAML and/or OIDC IdP service included with their MS365 or Google Workspace tenant.
So as a result, I select away from those offerings if there are comparable alternatives, and there almost always are.
I am not advocating for the use of social IdP (“Sign in with [Apple|Microsoft|Google|etc]”) for anything. I really dislike those as well, to the point that I actively select against services that only support signing in with a third party that I can’t control. I was specifically talking about SSO as it’s traditionally interpreted: SAML, OIDC, LDAP, etc that you control.
"SSO refers to a SaaS or similar vendor allowing a business client to manage user accounts via the client’s own identity provider, without having to rely on the vendor to provide strong authentication with audit logs, and with the ability to create and delete user accounts centrally, for all users, across all software in use by that client."
It’s certainly not a SaaS-centric thing. SSO has been around once before we used it widely with HTTP.
I would also argue that the last part conflates SSO and SCIM. Usually these are kept as distinct features, even if compatible.