|
|
|
|
|
|
by WorldMaker
1158 days ago
|
|
|
One view of it is that owning a database of passwords is a massive liability in 2023. Both in the cost sense and the legal sense. Building/maintaining/securing it costs more than most people want to think it does (especially if you need to pay for regular external audits, which is mandatory in some industries). The legal risks if that database falls into the wrong hands are enormous. (There are plenty of class action lawsuits every year when breaches of passwords are discovered.) It's very nice to externalize that liability/risk as much as you can. Hopefully standards like Passkey will help make that much easier to do without third party middle providers like Auth0/Okta/et al. > Presumably there isn't a migration workflow away from these products, save for asking your customers to perform a manual action. In my experience most third-party auth providers give you email addresses and correlating accounts by email address often does 80%-90% of the work. You can often script adding all your current user emails as users in the new system and give them unset/invalid passwords. You just can't prevent the need for manual password resets under the new auth provider, but often that is the only manual step and it is a common "Forgot Password" workflow so it will feel familiar/easy enough to most users. |
|
|
Regulators love to remind: you can't outsource your risk.
Your firm is accountable if customer data is stolen, which is what would happen if the passwords are compromised.
Even if it's "only" lost creds, your firm will still absorb the full "reputation risk" hit. No customer or reporter is going to say "well, but you didn't really lose your customers' passwords, it's the third party provider you chose." They'll hold you accountable.
That said, using a "Sign in with Microsoft" button means some 70%-80% of SMBs can use you without you having to have or outsource their creds, since they can just sign in as their emails/passwords from O365. For most of the rest, "Sign in with Google" picks them up. And, of course, get a majority of US consumer "wallet share" with "Sign in with Apple".
A small (and big) business sign in page would look like this (maybe without the GitHub):
https://login.tailscale.com/login
As another example for consumer logins, with FB, Discord, Twitter, along with the business domain logins:
https://www.xsplit.com/user/auth
The important one for small businesses trying to be compliant would be Continue with Microsoft for 0365 companies, while Continue with Google also gets you everyone in Google Workspaces.
"Real" SSO option could come later, as shown above Tailscale doesn't even have it. But these buttons are SSO as far as the typical user is concerned.
By using the logins the business users already have, nobody has to store creds for your B2B users but themselves.