12 ms·

This is my question as well. It's an honest question and hopefully someone can educate me. Why would anyone trust a third party with what is the most important

by taytus 6y ago

This is my question as well. It's an honest question and hopefully someone can educate me. Why would anyone trust a third party with what is the most important asset, their users? Thank you in advance.

kache_ 6y ago
It's much more lucrative for authentication/authorization/user management SaaS companies to build trust with their customers than to exploit that trust. Furthermore, with the economies of scale, there can be more investment done on security & protection of users by a common element. Think of it as a collection of companies pooling their resources on a single engineering team which is responsible for building a rock solid authentication system with many useful features. This helps little guys build on top of something which has the same efficacy as auth services that large companies can afford to build. At the end of the day, it's a trade off.
bsid 6y ago
Hey, Braden one of the founders. It's a good question, and a question that gets asked a lot. Out of curiosity would you trust a more established company like Auth0 or Firebase? We hope to gain developers trust over time, and we want to build a tool that makes it dramatically easier to build out session management, and a lot of these user flows. A similar question that was asked only a few (10?) years ago, was "why would I trust a third party with my credit card data?" And now it's something that people don't think twice about, because of all the regulatory challenges around storing credit cards, and how bad a breach is. We see auth, and more generically, basic user data, as a corollary to that. With User Data regulations popping up in different countries (GDPR/CCPA), in the next 5-10yrs, we think it will become pretty common place to use a service to offload some of these gnarly responsibilities.
- rapnie 6y ago
  > would you trust a more established company like Auth0 or Firebase? Auth0 maybe. Firebase is created by an advertising agency, so no.
- taytus 6y ago
  You didn't answer my question.
- ziftface 6y ago
  I can't speak for anyone else, but I would trust a service like this a lot more if i could easily export all my data. I would do so on a regular basis, basically as a backup. The other concern is what happens if you shut down or decide to change your plan to be prohibitively expensive? (I'm not implying that's the case for you, but it's a consideration that has to be made). There have been vendors in the past that have abruptly shut down without warning, leaving their customers scrambling to build or find alternatives. In all honesty, I'd rather build an authentication system from the beginning than having to take my service down at a critical time. This is actually a really interesting product though, and i would definitely consider it on future projects.
  - bsid 6y ago
    Thanks for the comment and consideration. Noted on exporting, glad to know that would help on the trust front. Definitely something we should prioritize. Gaining trust is hard, and something we hope to do over time. We of course don't want to shut down, and want to be a go-to for small projects, which would mean keeping pricing low. We think we'll be able to do that by up-charging on the B2B feature set.
tootie 6y ago
I can answer with the opposite question. Why would you trust your homemade solution instead of heavily invested experts? Auth0 (and Okta and a thousand others) do nothing but auth and customer management and do it at 1000X the scale as most enterprises. They do it way better than your IT team could possibly do it. And support every cutting edge feature and potential use case. You can also get them to absorb indemnity for damages in case of a breach rather than absorbing the cost yourself. From my POV, you'd be nuts to try to own your own passwords if you're securing anything remotely valuable.
- new_guy 6y ago
  Authentication is webdev 101. If you can't roll your own you're in the wrong industry. I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. The whole business model seems to revolve around being a crutch for people not capable or competent of running their own services.
  - tschellenbach 6y ago
    Well, if you look at how many sites break auth, or something in the login flow... This is clearly not the case for most companies. Auth is definitely simpler than most problems, but plenty of teams get it wrong.
  - chickenpotpie 6y ago
    > I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.
    - yannoninator 6y ago
      or, you could just do passwordless email auth and not have any security issues whatsoever.
camhart 6y ago
Most of the auth platforms I've used allow ways for you to migrate users off of their platform. You'd want to make sure at minimum you have their email address, but worse case scenario you'd require all users do a password reset essentially when you switch to the new auth provider. That's a horrible experience--but it's still an option. Better options actually allow you to migrate the user over as they login. You'd need to keep the "old" auth service around for a while though until you close the door on migrating. There's also an argument to be made that companies like this could (certainly not guaranteed) employ security experts and have better implementations (through libraries) as a result. Those implementations could (if updated appropriately), yield a more secure auth solution. In that regard, going with a third party, who has expertise, could be "better". Also, unless you're going to host your database that stores user data on prem, you're likely trusting a cloud with it. If I missed the point of your question I'm sorry. Did my best to answer. I have no relation to any of these services, other than I've used some at times throughout my career.
mooreds 6y ago
Hiya, First off, full disclosure: I don't work for Clerk; I work for a competitor which offers overlapping functionality, FusionAuth: https://fusionauth.io https://fusionauth.io I think a sibling comment laid it out well. It's a tradeoff. You are giving up some control over how your users are stored for significant acceleration of functionality. We've had customers say we saved them 1-2 person months of time in initial build, never mind ongoing maintenance. Would you build an app using a database managed by someone else? Isn't data a crucial asset? Some call it the new oil, I've heard. Yet lots of people choose to use an outsourced database provider. Auth is more user facing than a database, but if you can get the data out, what's the difference? That said, you should pick your own comfort level. Other options include self hosting (there are commercial and OSS solutions which you can run on your own hardware). You should also have a frank conversation with any providers about their security posture (sounds like the Clerk folks are going to add some docs to their site about this, which is great.) Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate.
- deleted 6y ago
  [deleted]
- hmsimha 6y ago
  > Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate. It's not even worth evaluating at the free tier without this. I asked in their slack and they said they intend to support this, which is promising (though sounds like it's not implemented yet)
notJim 6y ago
I have limited dev cycles, and would prefer to work on my product rather than google "how long does password reset token need to be" and writing auth forms.

by taytus 6y ago

kache_ 6y ago

It's much more lucrative for authentication/authorization/user management SaaS companies to build trust with their customers than to exploit that trust. Furthermore, with the economies of scale, there can be more investment done on security & protection of users by a common element. Think of it as a collection of companies pooling their resources on a single engineering team which is responsible for building a rock solid authentication system with many useful features. This helps little guys build on top of something which has the same efficacy as auth services that large companies can afford to build. At the end of the day, it's a trade off.

bsid 6y ago

Hey, Braden one of the founders. It's a good question, and a question that gets asked a lot. Out of curiosity would you trust a more established company like Auth0 or Firebase? We hope to gain developers trust over time, and we want to build a tool that makes it dramatically easier to build out session management, and a lot of these user flows. A similar question that was asked only a few (10?) years ago, was "why would I trust a third party with my credit card data?" And now it's something that people don't think twice about, because of all the regulatory challenges around storing credit cards, and how bad a breach is. We see auth, and more generically, basic user data, as a corollary to that. With User Data regulations popping up in different countries (GDPR/CCPA), in the next 5-10yrs, we think it will become pretty common place to use a service to offload some of these gnarly responsibilities.

rapnie 6y ago
> would you trust a more established company like Auth0 or Firebase? Auth0 maybe. Firebase is created by an advertising agency, so no.
taytus 6y ago
You didn't answer my question.
ziftface 6y ago
I can't speak for anyone else, but I would trust a service like this a lot more if i could easily export all my data. I would do so on a regular basis, basically as a backup. The other concern is what happens if you shut down or decide to change your plan to be prohibitively expensive? (I'm not implying that's the case for you, but it's a consideration that has to be made). There have been vendors in the past that have abruptly shut down without warning, leaving their customers scrambling to build or find alternatives. In all honesty, I'd rather build an authentication system from the beginning than having to take my service down at a critical time. This is actually a really interesting product though, and i would definitely consider it on future projects.
- bsid 6y ago
  Thanks for the comment and consideration. Noted on exporting, glad to know that would help on the trust front. Definitely something we should prioritize. Gaining trust is hard, and something we hope to do over time. We of course don't want to shut down, and want to be a go-to for small projects, which would mean keeping pricing low. We think we'll be able to do that by up-charging on the B2B feature set.

tootie 6y ago

I can answer with the opposite question. Why would you trust your homemade solution instead of heavily invested experts? Auth0 (and Okta and a thousand others) do nothing but auth and customer management and do it at 1000X the scale as most enterprises. They do it way better than your IT team could possibly do it. And support every cutting edge feature and potential use case. You can also get them to absorb indemnity for damages in case of a breach rather than absorbing the cost yourself. From my POV, you'd be nuts to try to own your own passwords if you're securing anything remotely valuable.

new_guy 6y ago
Authentication is webdev 101. If you can't roll your own you're in the wrong industry. I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. The whole business model seems to revolve around being a crutch for people not capable or competent of running their own services.
- tschellenbach 6y ago
  Well, if you look at how many sites break auth, or something in the login flow... This is clearly not the case for most companies. Auth is definitely simpler than most problems, but plenty of teams get it wrong.
- chickenpotpie 6y ago
  > I really can't think of any good reason to hand crucial control of a site over to any third party, much less user authentication where one breach will potentially cost you millions and land you in jail. Because Auth0 and other providers have security experts specializing in prevent hacking attempts and there is no way you can do a better job than them unless you make it your full time job.
  - yannoninator 6y ago
    or, you could just do passwordless email auth and not have any security issues whatsoever.

camhart 6y ago

Most of the auth platforms I've used allow ways for you to migrate users off of their platform. You'd want to make sure at minimum you have their email address, but worse case scenario you'd require all users do a password reset essentially when you switch to the new auth provider. That's a horrible experience--but it's still an option. Better options actually allow you to migrate the user over as they login. You'd need to keep the "old" auth service around for a while though until you close the door on migrating. There's also an argument to be made that companies like this could (certainly not guaranteed) employ security experts and have better implementations (through libraries) as a result. Those implementations could (if updated appropriately), yield a more secure auth solution. In that regard, going with a third party, who has expertise, could be "better". Also, unless you're going to host your database that stores user data on prem, you're likely trusting a cloud with it. If I missed the point of your question I'm sorry. Did my best to answer. I have no relation to any of these services, other than I've used some at times throughout my career.

mooreds 6y ago

Hiya, First off, full disclosure: I don't work for Clerk; I work for a competitor which offers overlapping functionality, FusionAuth: https://fusionauth.io https://fusionauth.io I think a sibling comment laid it out well. It's a tradeoff. You are giving up some control over how your users are stored for significant acceleration of functionality. We've had customers say we saved them 1-2 person months of time in initial build, never mind ongoing maintenance. Would you build an app using a database managed by someone else? Isn't data a crucial asset? Some call it the new oil, I've heard. Yet lots of people choose to use an outsourced database provider. Auth is more user facing than a database, but if you can get the data out, what's the difference? That said, you should pick your own comfort level. Other options include self hosting (there are commercial and OSS solutions which you can run on your own hardware). You should also have a frank conversation with any providers about their security posture (sounds like the Clerk folks are going to add some docs to their site about this, which is great.) Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate.

deleted 6y ago
[deleted]
hmsimha 6y ago
> Another consideration: you want the ability to export your users should you want to move services. People who aren't self hosting with FusionAuth can get a database export from us, for example, if they want to migrate. It's not even worth evaluating at the free tier without this. I asked in their slack and they said they intend to support this, which is promising (though sounds like it's not implemented yet)

notJim 6y ago

I have limited dev cycles, and would prefer to work on my product rather than google "how long does password reset token need to be" and writing auth forms.