Why does Firebase auth uses a “middleware” redirect before returning to my app?












2















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?










share|improve this question



























    2















    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?










    share|improve this question

























      2












      2








      2








      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?










      share|improve this question














      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?







      firebase oauth-2.0 firebase-authentication






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Dec 31 '18 at 18:58









      Samuel E.Samuel E.

      6412716




      6412716
























          2 Answers
          2






          active

          oldest

          votes


















          1














          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.






          share|improve this answer
























          • Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

            – Samuel E.
            Jan 2 at 9:05











          • There are no public docs on this endpoint.

            – bojeil
            Jan 3 at 2:42



















          0














          The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.



          The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.



          This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.






          share|improve this answer
























          • Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

            – Samuel E.
            Jan 1 at 7:14











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53990604%2fwhy-does-firebase-auth-uses-a-middleware-redirect-before-returning-to-my-app%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          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.






          share|improve this answer
























          • Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

            – Samuel E.
            Jan 2 at 9:05











          • There are no public docs on this endpoint.

            – bojeil
            Jan 3 at 2:42
















          1














          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.






          share|improve this answer
























          • Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

            – Samuel E.
            Jan 2 at 9:05











          • There are no public docs on this endpoint.

            – bojeil
            Jan 3 at 2:42














          1












          1








          1







          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.






          share|improve this 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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 2 at 7:37









          bojeilbojeil

          13k11825




          13k11825













          • Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

            – Samuel E.
            Jan 2 at 9:05











          • There are no public docs on this endpoint.

            – bojeil
            Jan 3 at 2:42



















          • Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

            – Samuel E.
            Jan 2 at 9:05











          • There are no public docs on this endpoint.

            – bojeil
            Jan 3 at 2:42

















          Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

          – Samuel E.
          Jan 2 at 9:05





          Do you know if there is any public docs on that endpoint in order to take advantage of it in my custom auth library?

          – Samuel E.
          Jan 2 at 9:05













          There are no public docs on this endpoint.

          – bojeil
          Jan 3 at 2:42





          There are no public docs on this endpoint.

          – bojeil
          Jan 3 at 2:42













          0














          The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.



          The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.



          This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.






          share|improve this answer
























          • Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

            – Samuel E.
            Jan 1 at 7:14
















          0














          The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.



          The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.



          This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.






          share|improve this answer
























          • Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

            – Samuel E.
            Jan 1 at 7:14














          0












          0








          0







          The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.



          The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.



          This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.






          share|improve this answer













          The myapp.firebaseapp.com/__/auth/handler is the URL that signs your users in with Firebase Authentication.



          The accounts.google.com/o/oauth2/v2/auth URL signs you in with Google OAuth, but not with Firebase.



          This flow is the same for all OAuth2 providers that Firebase supports. So if you'd sign in with Facebook, you'd see firebase auth handler -> facebook oauth handler -> firebase auth handler.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 1 at 3:18









          Frank van PuffelenFrank van Puffelen

          235k29381407




          235k29381407













          • Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

            – Samuel E.
            Jan 1 at 7:14



















          • Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

            – Samuel E.
            Jan 1 at 7:14

















          Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

          – Samuel E.
          Jan 1 at 7:14





          Thank you for the help. What I don’t understand is why add that redirect in the middle when there is a REST API for that? I assume that the Firebase handler does something in addition to logging you since you can log the user in with the token from the Federated identity provider without the need for that handler. (That’s what is usually done)

          – Samuel E.
          Jan 1 at 7:14


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53990604%2fwhy-does-firebase-auth-uses-a-middleware-redirect-before-returning-to-my-app%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Angular Downloading a file using contenturl with Basic Authentication

          Olmecas

          Can't read property showImagePicker of undefined in react native iOS