如果我要完全集成Janrain Social Login或Oneall，迁移到我自己的自定义系统会遇到什么障碍？
例如，许多开发人员使用Janrains社交插件（以及其他许多插件），因为他们没有时间编写所有代码来提供自己的解决方案，或者因为它快速方便。
然而，在未来的某个地方，也许当开发人员有更多的时间时，他可能会使用OpenID选择器和OpenID库（例如stackoverflow自己的解决方案）来编写自己的解决方法。此外，Janrain和Oneall变得昂贵，获得最初的几千名用户是件好事，但在用户注册量突然增加后，它变得非常昂贵（尤其是如果你只使用社交登录，而不是其他社交功能）
我看到的问题是，在我的facebook应用程序中，我给FB应用程序的网站URL（例如oneall）是"http://myapp.api.oneall.com/'它将处理所有验证并链接帐户，然后重定向到我的网站回调url。
然而，如果我用自己的解决方案取代Oneall（网站URL将更改），会发生什么？然后身份验证将变为无效，不是吗？并且用户将不得不再次接受权限？如何成功迁移？
我希望我已经解释得足够好了。也许这是微不足道的，但如果能澄清一下，我们将不胜感激。我想确保我不会被Oneall或Janrain束缚。
我对Oneall没有太多经验，但Janrain使Engage服务尽可能无缝和非侵入性。换句话说，无论发生什么情况，您都可以保留您的用户数据。这就是Janrain提供API端点的原因，您可以自由调用并以任何方式保留配置文件数据。Janrain Engage不会在服务器上存储任何用户数据，如果你打算离开，他们也不会拒绝访问。
例如，如果你有一个Wordpress网站，并使用我们的Engage小部件插件来获取传统的以及社交登录的用户数据，即使你删除了Engage小程序，你也会保留这些Wordpress用户。他们的登录体验在事后也没有改变。
当然，当开发人员有时间和资源来构建一个本土网站时，他们必须按照服务器端管理用户配置文件的方式进行编程。