SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
I don’t know when we became this lazy. Auth is hard, sure, but putting your users table and sessions behind a vendor API is not something cool. Tell me one feature that is not supported by libraries like OpenIddict (You can build around) or Keycloak?
I think the main argument usually is time savings. Personally I just always do E-Mail and password auth, yea its old and not the shiny new thing, but it doesn't require me to integrate 200 different ways of doing auth.
We should be able to demand users remembering their passwords, I dont like to cater towards users who simply dont want to put in the work to use my product.
Will I lose potential users over this? Yes. Does it feel bad knowing I am in control and wont have to offload to 3rd party vendors? Hell no.
Great for you but that's not the case for a lot of B2B contracts we have. A lot of them require integrating with their SSO, not just for login but for permissions too
Do permissions follow the same model everywhere with SSO or do you now have to set up permission logic everywhere for new customers? Like company A uses "admin" as role while company B uses "management" for essentially the same role?
Same here, Just email + password, no google dependency initially. If more users ask we will think of it. but again you don't need a cloud vendor for all this.
You do you but most businesses if given the option between supporting OAuth to reduce friction on signups, or only supporting password auth, will choose the option that makes them more money.
You don't have to use a 3rd party service for OAuth. You can do it in house.
Yea I know, I just don't want my app to have a google logo on it, or whatever other companies people use to login with. E-mail and password will forever be my go to solution.
I want intentional users not the ones that click "sign up with google", try out the app once and never come back. Also I don't have the time to learn how to properly integrate more auth methods into my app. I want my own user table, I want predictability on how a user model looks and I want to be in control of everything.
If you're a SaaS vendor, you want to make onboarding and logging in as easy as possible and being able to do things like add a "login with google/apple" button or other third party SAML/SSO tooling is one way to do that. Supporting that workflow sucks as it can involve very finicky integrations involving certificate trusts, etc.
Those authentication providers require you to do the same Google/Apple OAuth certificate configuration yourself, and you even have to pay the 99 euros for Apple.
SAML/SSO is indeed finicky, but the problematic part (mapping attributes) is often done by IT teams, ESPECIALLY if you use a third-party provider.
Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.
> For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
fwiw, we also have entire staff dealing with SSO issues among our employees and users, despite relying on external services to handle auth.
A problem domain as complex as authentication is bound to habe issues of some sort. But I am not sure if I would be so fond of „outsourcing“ something as integral to my services as the access to these services
There is a trust component for sure, but a business requires assessing the value of time against revenue. I can say for our org that using an off the shelf solution like Clerk saves us time and money and we believe the risk is very small relative to the savings. Maybe the cost for you is not large right now, but when you've got 20 enterprise customers all asking for specific OIDC integrations configured with Private Link, custom domains, and private clusters, an auth solution starts looking mighty fine.
SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec.
For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.