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

Multi tool use
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
add a comment |
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
add a comment |
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
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
firebase oauth-2.0 firebase-authentication
asked Dec 31 '18 at 18:58
Samuel E.Samuel E.
6412716
6412716
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
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
add a comment |
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
.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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
.
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
add a comment |
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
.
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
add a comment |
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
.
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
.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
dLxOkKiKgF9EftyodjMjq de4CWE8tSeyht5Y3O2ddIgYPhTc,VWP8LA,d0fxpngl4j aK8HnEtDrtA2 bqeU7dcSahqZswM