我正在从一个cordova应用程序运行一个网络视图，并希望对用户进行身份验证，我知道他们有OAuth策略，但我需要使用电子邮件/密码组合。
我想让事情变得简单，但最终可能不得不生成一个令牌。
- 打开加载firebase的身份验证流的InAppBrowser
- 侦听要使用以下方法完成的身份验证流：http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inapp浏览器
- 再次从webview获取结果，并将其插入到webview firebase实例中
我猜由于安全原因，这是不可能的。
我的应用程序正在使用亚马逊登录（必需），所以我的替代方案是：
- webview使用我们的外部url加载InAppBrowser
- 加载Amazon身份验证，然后为Firebase生成令牌
- webview侦听令牌并获取它，将其存储在本地存储中
编辑：在使用用户名/密码登录的firebase文档中，我看到它返回会话的令牌以及authData对象中的更多信息：https://www.firebase.com/docs/web/guide/user-auth.html
然后，我可以从该对象中获取所有信息，并将其发送回cordova网络视图，然后用信息填充Firebase引用吗？
来自Firebase的一些非常有用的支持的答案：
第一：
你是对的——任何人都可以提出注册请求，我们不提供任何保护url的功能，人们可以从该url注册以进行电子邮件/密码验证。
我们要求/启用OAuth身份验证的原始白名单，而不要求/启用电子邮件/密码身份验证的主要原因往往围绕会话。
Firebase登录服务器不维护会话（通过Cookie或任何其他方法），因此请求登录服务器进行密码验证。每个请求都需要一个用户凭据（密码）。当恶意方可以利用用户的会话浏览器时，即代表用户向浏览器自动发送cookie的某个页面发出请求时，CSRF通常是一种风险。
此外，对于这些纯HTTP请求，我们没有一个很好的方法来真正实现理想的基于源的白名单。我们可以使用CORS，但对于不支持它的旧浏览器环境，必须求助于JSONP。更复杂的是，PhoneGap/Cordova应用程序根本没有相同的"来源"概念，而且从服务器的角度来看，这些调用与任何恶意方用相同的头发出HTTP请求是无法区分的。
然而，OAuth提供者使用cookie进行会话，并且不需要用户为每个auth发明。要求如果你已经批准了一个特定的Facebook应用程序，下次该应用程序请求你的数据时，你不会看到任何UI/UX，也不会得到提示——它将是不可见的。当我们进行OAuth时，我们永远不需要向Facebook.com/Twitter.com/等发送任何用户凭据，因为这些凭据存储在Facebook.com/Twiter.com/等的浏览器cookie中。我们需要保护的是恶意方假装是流行的、有效的Facebook应用程序。以及利用在用户不知情的情况下访问用户数据的短路行为。
我的回应：
那么，这是如何保证的呢？如果有人可以从cordova网络视图（没有特定的url，只有应用程序iteself）那么我无法确保人们可以从哪个url注册？所以任何网站可以在他们的配置中使用我们的url"xxx.com"并开始注册用户？
我觉得这不对。
我想我仍然需要一个被你列入白名单的外部url伙计们。这将有登录表单并进行身份验证。
但我的问题是，我可以将该授权转移回我的cordova应用程序吗？它在本地存储的某个地方我可以检查吗？我得做一些测试。
最终回应：
当然——我们很乐意提供帮助。我写了很多原始的客户端身份验证代码，可以讨论其中的设计决策和基本原理。如果你有进一步的问题，一定要告诉我。
当然，虽然我们不将用户密码存储在cookie中，但我们维护Firebase身份验证。LocalStorage中的令牌。我们的身份验证令牌由您唯一的Firebase密钥签名（因此它们不会被欺骗），并且可以包含任何在您的安全规则中有用的任意用户数据。
默认情况下，当使用委派登录（电子邮件+密码）服务时，这些令牌将只包含一个用户id，用于唯一标识您的用户，以便在安全规则中使用。例如，您可以通过令牌中的用户id（".write"="$uid=auth.uid"）将所有写入或读取限制在给定的路径（例如写入/users/$uid/name）。有关该主题的更多信息，请访问我们的网站。
你计划启动一个服务器来向亚马逊验证用户并生成代币，这听起来是正确的。对于那些希望使用我们不支持开箱即用的身份验证方法（即Amazon OAuth）或具有自定义身份验证要求的用户来说，这是一种常见的模式。注意：一旦您创建了这些令牌并将其发送到客户端，一旦您调用
ref.authWithCustomToken(…)，它们将自动为您持久化。应用程序的后续重新启动将使用相同的令牌，只要它尚未过期。
这也是我感兴趣的话题，因为我已经在webview中实现了类似的东西，twitter数字（原生android）+firebase自定义登录。
我认为，根据firebase的建议，您可以使用其他身份验证提供商，然后使用firebase自定义登录。
你在android原生代码中使用亚马逊登录吗？如果登录后是这样，那么为firebase生成一个JWT令牌，并使用它访问firebase。如果所有代码都在Html/js应用程序中，那么也许你可以使用自定义登录，并在确保服务器登录到亚马逊后在服务器上生成令牌。
Android混合应用程序的问题如下：JWT令牌（用于firebase）应该在安全系统（例如服务器端）上创建，而不是使用Android java代码，混合应用程序中的另一个选项是执行http请求来生成令牌，但我发现不太安全，任何人都可以通过查找URL来获得令牌，而不是我在Android应用程序代码中生成令牌，在发布新版本时，您可以更改token的安全密钥/种子。
总之，我不认为firebase研究了移动混合应用程序的问题。