javascript - Cordova /Phonegap 中的 Firebase : Log in using Email/Password from within app?

Question

我正在从 cordova 应用程序运行 Web View ，并且想要对用户进行身份验证，我知道他们有 OAuth 策略，但我需要使用电子邮件/密码组合。

我想让事情变得简单，但最终可能必须生成 token 。

• 打开一个 InAppBrowser，为 Firebase 加载身份验证流程
• 监听使用此方法完成的身份验证流程:http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
• 再次从 webview 中获取结果并将其插入到 webview firebase 实例中

我猜由于安全原因这是不可能的。

我的应用程序正在使用亚马逊登录(必需)，因此我的替代方案是:

• webview 使用我们的外部 URL 加载 InAppBrowser
• 加载 Amazon 身份验证，然后为 Firebase 生成 token
• webview 监听 token 并抓取它，将其存储在本地存储中

编辑:在使用用户名/密码登录的 firebase 文档中，我看到它返回 session 的 token 以及 authData 对象中的更多信息: https://www.firebase.com/docs/web/guide/user-auth.html

然后我可以从该对象中获取所有信息并将其发送回 cordova webview，然后使用该信息填充该 Firebase 引用吗？

Answer 1

来自 Firebase 非常有用的支持的一些答案:

第一:

You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.

The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.

The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.

Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.

The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.

我的回应:

So, how is that secured? If anyone can make a request to sign up from a cordova webview (which comes from no specific url, just the app iteself) then I can't secure from which url people can sign up from? So any site could use our url "xxx.com" in their config and start registering users?

That doesn't seem right to me.

I think I still need to have an external url that is whitelisted by you guys. That would have the login form and do the auth.

But then my question is, can I transfer that auth back to my cordova app? Is it somewhere in localStorage I can check? I'll have to run some tests.

最终回应:

Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.

While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.

By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.

Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.