How do “Authorized Domains” work?

[Vlad GURDIGA]

Hey guys!

The docs say:

For security reasons, only domains that you whitelist are allowed to initiate authentication for your app. All Firebases have localhost, 127.0.0.1 enabled by default for local development and testing.

What I thought this means is: an in-browser web app can only register/authenticate users with my Firebase if the app’s URL is in the whitelist.

But I just realized that although my Firebase has the default whitelist — localhost, 127.0.0.1, pinj-dev.firebaseapp.com — it still authenticates fine, I mean I can register/authenticate on my production website even if it’s not in the whitelist. Now I’m starting to consider the version where I didn’t quite understand how that whitelist works.

Could you please shed some light on my story?

[Michael Wulf]

Vlad,

I'm working with the engineers to get some clarification here. Hang in there while I investigate.

Cheers,

Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jacob Wenger]

Hey Vlad,

Thanks for reaching out. Ultimately, our docs/UI have led to some confusion here. The short answer to your question is that for email/password auth, the whitelisted domains do not apply. Those domains also don't apply with anonymous auth and custom auth. They only apply with the four OAuth providers. I won't go into the details over why this is the case (although I can if you'd like), but there are no security problems with this approach and what you are seeing is expected behavior.

I've opened up tasks to clean up several things in this area. We will first improve our docs to explain the situation better and remove this confusion. We will also clean up the UI in the Firebase dashboard to make it clearer what the authorized domains apply to.

Sorry this lead to some confusion.

Jacob

On Friday, October 3, 2014 8:36:15 AM UTC-7, Michael Wulf wrote:

Vlad,

I'm working with the engineers to get some clarification here. Hang in there while I investigate.

Cheers,

Kato

On Fri, Oct 3, 2014 at 5:57 AM, Vlad GURDIGA <gur...@gmail.com> wrote:

Hey guys!

The docs say:

For security reasons, only domains that you whitelist are allowed to initiate authentication for your app. All Firebases have localhost, 127.0.0.1 enabled by default for local development and testing.

What I thought this means is: an in-browser web app can only register/authenticate users with my Firebase if the app’s URL is in the whitelist.

But I just realized that although my Firebase has the default whitelist — localhost, 127.0.0.1, pinj-dev.firebaseapp.com — it still authenticates fine, I mean I can register/authenticate on my production website even if it’s not in the whitelist. Now I’m starting to consider the version where I didn’t quite understand how that whitelist works.

Could you please shed some light on my story?

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

[Gordon Zhu]

Hi Jacob,

Can you explain why not having whitelists for email/password auth isn't a security issue?

I think I know what you're going to say but I'd rather have the satisfaction of getting an official answer.

Thanks,

Gordon

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

[Michael Wulf]

Hi Gordon,

I asked this same question recently. Here's an almost verbatim answer I received from Rob, another of our auth experts:

Without getting in to the technical details, the key difference that I would draw between password authentication and OAuth authentication, with respect to the restrictions around originating origin, is 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 only 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. Since we don't have this type of persistent sessioning, or use cookies at all, we're not at risk.

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.

In short, email/password auth has its own unique set of privileges, restrictions, and challenges; but, CSRF isn't applicable in that case.

Cheers,

Kato