Except if you're setting up SSO for your company's employees. Using a 3rd party login provider is a necessity. You shouldn't trust employees to create unique / strong passwords for every individual service they login to.
Or if you're setting up a SaaS application where some of your customers will want integration with their own SSO. We don't have developer time to spare implementing that sort of thing but Auth0 lets us do it as one of its built-in integrations.
It lets us offer SSO with whatever Auth0 supports as a freebie add-on, instead of "well, we could work with your platform but it's gonna cost you."
I don't see how it's a trap, except that we have to pay auth0 a monthly fee to handle our authentications instead of having some number of hours a month spent maintaining and securing our customers' logins and integrations.
Not only that. As a user it's incredibly frustrating entering a password 5 or more times each morning. This results in users using extremely weak passwords.
The same is true for forcing users to reset their password every 50 days or so, by the way. This outdated password guideline doesn't seem to die. I know way to many cases where people are using a weak base password with a number attached to it because they got sick of trying to remember a new password every month.
> The same is true for forcing users to reset their password every 50 days or so, by the way. This outdated password guideline doesn't seem to die. I know way to many cases where people are using a weak base password with a number attached to it because they got sick of trying to remember a new password every month.
there are people who actually invent a new password every time instead of cycling numbers?
also, change password a few times until history is flushed and switch back to the same password you started with is a thing.
SSO is more than password management. It is instant provisioning and deprovisioning of users. Role management and auditing. Enforcement of security standards like 2FA in a central place.
Not really relevant for the specific topic, but to be more precise, SSO is only the sign on part. Usually the provisioning/de-provisioning is handled by SCIM, which is related but distinct. You have some SaaS products that offer SSO but not SCIM, for example.
Sorry, I should have been more clear. When I typed SaaS products I meant more about a non-IDP product. They might support SSO but not SCIM-based account provisioning, especially if it's in-house auth (not using something like Auth0). I worked on a product that supported SSO but not SCIM for a long time and not all SCIM features were supported.
I've used Okta to provide gateway access to physical devices and AWS roles in the same deployment. Very impressive when every endpoint and SaaS product is behind a single 2FA login.
If you can enforce that they use the password manager, it solves that one problem.
But SSO centralizes access management. For instance, with one switch I can set password requirements, require 2FA, and grant/revoke access to all of an employee's services when they join the company or leave.
I'm sure there are ways to use 2FA or OTP without externalising access management to Facebook, Google or another SSO provoder, unless you want to pick convenience over privacy and security.
How do you enforce it over a bunch of 3rd party software which either doesn't support 2FA or doesn't support enforcing it? If they support SSO which they usually do, its a non issue.
How do you centralized your authn, your 2fa provisioning? How do you ensure that your cloud native apps have access to the auth backend without risking exposing the wrong ports on the wrong vpc?
Just adding a library to application code is not sufficient. What I mean is that organizations should not roll their own SSO provider. At the very least, work with one of the many companies that offer it as a product or service. If your threat model requires it, you can host the product on premises.
Except if you're setting up SSO for your company's employees. Using a 3rd party login provider is a necessity. You shouldn't trust employees to create unique / strong passwords for every individual service they login to.