Ad

Why Does Firebase Auth Uses A "middleware" Redirect Before Returning To My App?

- 1 answer

I'm trying to add authentication to my web app by using Firebase Auth and I would like to avoid using the Firebase JS SDK because it's too big in my opinion, and also as an exercise for getting to know the underlying protocols better.

I've noticed that the Firebase Auth SDK doesn't directly redirect to the OAuth endpoint and then back. Instead, it redirects to https://my-app.firebaseapp.com/__/auth/handler which then redirects into the OAuth endpoint with itself as a callback, and then back into my requested callback URL.

So basically instead of:

myapp.com
   ↓
accounts.google.com/o/oauth2/v2/auth
   ↓
myapp.com

This happens:

myapp.com
   ↓
myapp.firebaseapp.com/__/auth/handler
   ↓
accounts.google.com/o/oauth2/v2/auth
   ↓
myapp.firebaseapp.com/__/auth/handler
   ↓
www.myapp.com

I couldn't find any documentation about this API anywhere, but I think that maybe it's an internal middleware for CSRF prevention, or maybe just an API that does the heavy lifting of closing the gap between different Federated Identity APIs.

The reason I'm interested in this is that it can save me some time and possibly money if it does one of the above, and I'm pretty sure I might learn something new from it(I at least hope so).

So, what is the https://my-app.firebaseapp.com/__/auth/XXX endpoint used for, and is there any docs on using it?

Ad

Answer

It is mostly for ease of use and convenience. You just use one whitelisted callback URL for all your OAuth providers (set up just one redirect URL for all your OAuth providers). You don't have to worry about hosting it as Firebase Auth does that for you. Now you can host your application in multiple domains for production, localhost for development, etc. As long as these are whitelisted in your project, you can sign in with any OAuth provider of your choosing. You can add and remove whitelisted domains from one place in your project settings. Note some OAuth providers in the past used to allow only one callback URL. This would have bypassed that limitation.

It will also work for popup flows too as well as the typical OAuth redirect flow. For example, many developers choose to use popup flows for desktop and redirect for mobile devices.

Notice also for the redirect flow, it does not pass the OAuth authorization code, etc back to your webpage via URL query string, instead it does that via iframe postMessage. So the redirect back to the original URL will have the exact same URL, unmodified. So you can start with https://www.example.com/#login and then go back to same URL to complete login.

In addition, it does not require server side code as is typically done with express passport, etc. No boilerplate code too.

Ad
source: stackoverflow.com
Ad