4 ms·

I have a question, although it's not about this product in particular. I started building web apps before Auth0, Okta and friends arrived on the scene so I nev

I have a question, although it's not about this product in particular. 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?

mkl 3y ago
I agree, it seems like a strange risk. How easy is it to change authentication provider? How disruptive is that for customers? I have no experience with this sort of thing, but would like to understand.
- dave_kinde 3y ago
  It varies from provider-to-provider. With Auth0 you have to install a plugin from their marketplace to get an export. If you want the hashed passwords exported you have to email their support team and they pull it together for you - usually takes about 2 weeks. 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
  - gtsteve 3y ago
    That's really good and thanks for responding to the question. I think I could be tempted to try a service like this for a future project. 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.
    - connorkinde 3y ago
      Trust me when I say that we're paranoid about data too. Our security specialist was the second hire. 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
    - dave_kinde 3y ago
      That's right, bcrypt2 - we also upgrade imported users passwords to this more secure hashing algorithm if they were previously using something less secure like md5. This is all done transparently on their first login with no impact to the user flow. 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
xyst 3y ago
The value is always decreased costs in managing itself, “cleaning self of security breaches” but like you said the trade off is that it’s a single point of failure. If that company becomes defunct or a security issue arises (ie, poorly implemented specs or malicious employee) then your company is now racing to migrate off. 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.
dlisboa 3y ago
This kind of service helps you get off the ground much faster. Adding a few social logins, plus email/password, plus MFA is not necessarily slow but it's not fast when you have to create the whole backend. 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.
- mooreds 3y ago
  Disclosure. I work for an auth vendor, FusionAuth. > 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.
riogordo2go 3y ago
I find it somewhat annoying to see the intense community pressure to go with third party auth providers. I see auth, user and role/permission management as a core pilar of an online business and would think long and hard before handing this over. I realize doing this yourself requires a big investment in studying proven security practices and finding well established libraries, but I think it's well worth it.
WorldMaker 3y 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.
- Terretta 3y ago
  > externalize that liability/risk 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 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 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.

mkl 3y ago

I agree, it seems like a strange risk. How easy is it to change authentication provider? How disruptive is that for customers? I have no experience with this sort of thing, but would like to understand.

dave_kinde 3y ago
It varies from provider-to-provider. With Auth0 you have to install a plugin from their marketplace to get an export. If you want the hashed passwords exported you have to email their support team and they pull it together for you - usually takes about 2 weeks. 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
- gtsteve 3y ago
  That's really good and thanks for responding to the question. I think I could be tempted to try a service like this for a future project. 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.
  - connorkinde 3y ago
    Trust me when I say that we're paranoid about data too. Our security specialist was the second hire. 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
  - dave_kinde 3y ago
    That's right, bcrypt2 - we also upgrade imported users passwords to this more secure hashing algorithm if they were previously using something less secure like md5. This is all done transparently on their first login with no impact to the user flow. 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

xyst 3y ago

The value is always decreased costs in managing itself, “cleaning self of security breaches” but like you said the trade off is that it’s a single point of failure. If that company becomes defunct or a security issue arises (ie, poorly implemented specs or malicious employee) then your company is now racing to migrate off. 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.

dlisboa 3y ago

This kind of service helps you get off the ground much faster. Adding a few social logins, plus email/password, plus MFA is not necessarily slow but it's not fast when you have to create the whole backend. 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.

mooreds 3y ago
Disclosure. I work for an auth vendor, FusionAuth. > 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.

riogordo2go 3y ago

I find it somewhat annoying to see the intense community pressure to go with third party auth providers. I see auth, user and role/permission management as a core pilar of an online business and would think long and hard before handing this over. I realize doing this yourself requires a big investment in studying proven security practices and finding well established libraries, but I think it's well worth it.

WorldMaker 3y 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.

Terretta 3y ago
> externalize that liability/risk 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 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 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.