I have no experience with this sort of thing, but would like to understand.
Kinde has a self-serve export tool baked in as we believe it is important for people to be able to change provider freely and not have vendor lock-in. We also have a self-serve import tool for organizations and users including hashed passwords so there is no disruption to the end customer
I'm guessing the password hash format is something like bcrypt2? Is there an API for that? The feature quite nicely mitigates a situation where prices are unreasonably raised, but to mitigate a rug-pull event such as a business failure, malicious action or serious technical failure I'd probably want to automate this.
If that sounds like I'm sort of paranoid, it's probably because I am. I do this with all my company's cloud data.
It was a huge issue with Auth0 recently when they were bought by Okta. We've spoken to customers who have had their prices increased 2-20x virtually overnight with no forewarning and they've been forced to go through a process with customer support in order to get access to their user base and move off.
I'll get someone from the team with a better understanding of the password hashing to get back to you on this but I believe it's bcrypt2.
As Dave mentioned we're trying to make it as easy as possible to get your users out. I'll chat to someone from the team about the automation, it's an interesting idea
The self-service export is UI driven at the moment, as exporting passwords requires approval from an additional owner/admin for security. We could definitely extend this to be initiated by API though
Personally, I would rather manage it myself. I have found an open source system called Ory which allows you to fully customize the identity, federated identity support with other components (ie, act as your own IdP), highly scalable, offers ACLs, support for multi factor authentication, social login, and can fully customize the login experience to your liking.
I manage the deployment, upgrades, and monitoring through a series of helm charts and k8s. Their system is so efficient it can run entirely on a single node k8s cluster (ie, dev machine with minikube). Not going to lie, it’s definitely a lot of work but worth the trade off. No longer have to burn $$$ while testing simple flows in my apps.
In many applications identity is not the main part of the business. Once you're up and going you can devote time to identity management.
Obviously there are Open Source projects and libraries that do the same thing, but usually these companies have better docs and dashboards. So the value is just decreased initial cost at the expense of a possible outage or eventual disruption, but these things happen with any external provider, you just have to make the cost/benefit analysis.
A bit like e-mail: e-mail is usually a crucial part of the business too, but nearly no one manages their own e-mail service nowadays.
> A bit like e-mail: e-mail is usually a crucial part of the business too, but nearly no one manages their own e-mail service nowadays.
I liken it to a database. Most people use databases in their apps. Some people use a fully managed proprietary solution (graph db, dynamodb), others use a managed solution that conforms to a given standard (managed mysql/postgresql). Some people run databases themselves. But very few people would build a database from scratch.
Auth is much the same. You have a spectrum of needs, based on how much control you need. SaaS solutions get you functionality faster and with less maintenance while giving you less flexibility. Self-hosted solutions let you leverage the efforts of the OSS community or vendor while still maintaining operational control as well as data sovereignty.
Only a very few folks should write their own auth, it's a solved problem with lots of good solutions out there.
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.
I started building web apps before Auth0, Okta and friends arrived on the scene so I never considered until recently having someone else manage my authentication concerns. Identity is very important in most web applications so I was wondering what value a CTO gets from allowing someone else to manage it.
For example, I would be concerned about prices suddenly being increased or what happens if the business we relied on failed, lost accreditations, or suffered a serious security incident. Presumably there isn't a migration workflow away from these products, save for asking your customers to perform a manual action.
While clearly these services are very useful and popular, I just can't shake the feeling that it could be a very good way to get started, but a long term strategic mistake.
I was wondering if anyone from Kinde or with experience using these services long-term has any thoughts on this?