将Auth0与Parse Server / React Native应用程序一起使用的好处？

Question

我想知道与Auth0集成的其他复杂性与密码复杂性规则，UI等大量可用代码相关的其他复杂性，包括使用snowke starter app，用于使用开源解析服务器进行身份验证/用户创建。

我相信很多人已经考虑过这一点，并且想知道共识是什么？要求保持个人资料/电子邮件同步，依赖第三方，无法自定义视图，我相信很多其他问题。

起初我认为这很好，我不需要担心很多事情，但还有很多其他事情需要担心而且无法自定义。

最有说服力的“PRO”答案是什么？

Answer 1

_{披露：我是Auth0工程师。}

  

TL; DR ：我可以谈谈利弊，但最终答案需要由您提供。

关于Auth0

Auth0支持最广泛使用的身份验证协议（OAuth2 / OIDC，SAML和WS-Federation），因此集成到可以通过可用库说话或可以说话的自定义软件中相对容易且无摩擦。 _{Sidenote，Parse Server does seem to support integration with OAuth兼容身份提供者。}

它可以用作独立的身份提供商，您的用户可以使用特定于您的应用程序的用户名/密码凭据进行注册和身份验证，但它也可以与许多下游身份提供商集成，例如Google，GitHub和Twitter。这样就可以很容易地通过配置启用不同的用户身份验证方法，而不必直接与每个提供商交谈，并且必须处理他们的实现差异。

最后，它为您提供了足够的可扩展性点，使您仍然可以对身份验证体验进行显着程度的控制，例如：

• Rules（JS代码）允许您自定义身份验证过程
• Customization of Auth0 provided authentication user interface可让您仍拥有自己的品牌
• Customization of Lock可让您快速轻松地在自己的应用中集成自定义身份验证体验

当然，无论有多少延伸点，总会有一些你无法控制的东西。这可以被视为糟糕，但有时它实际上是一件好事。取决于观点和您的具体要求。

比较 - 滚动您自己的（RYO）与第三方服务

一方面，你有：

• 获得服务的成本
• 服务与产品集成的成本

另一方面，你有：

• 实施所需功能的成本
• 这些功能的拥有成本
• 产品中新功能的集成成本

在这两种情况下，您都需要进行一些集成工作，以便无论是谁创建零件都能使所有零件都适合。你可以争辩说，如果你是一切的作者，那么在圆孔中安装一个方形钉更容易，所以我们可以说RYO在这一点上获得了一小部分。

然后，所有这些都来自比较收购成本与实施和所有权成本。我无法回答这个问题，但收购成本通常很容易计算，而实施软件的成本很难预测;拥有自定义身份验证解决方案之外，还有一个沉重的代价...你知道他们说什么，没有人因为购买IBM而被解雇。我不会再这么做了，但是如果你自己安全起见，说你发现自己更容易被发现，这是安全的。 ：）

结论

完成Auth0试用版，使用它，查看它提供的内容以及符合您要求的内容。

如果您发现无法完成的任务，请在此处标记auth0或Auth0 Forums上的问题。