Login to Firebase does not work on Safari 16.1+

[mmmulani]

Describe your environment

• Operating System version: Mac OS 12.6
• Browser version: Safari 16.1
• Firebase SDK version: 9.10.0
• Firebase Product: auth

Describe the problem

Steps to reproduce:

Try logging in to a site using signInWithRedirect. Notably it redirects back to the site without an error, and does not log the user in. Checking getRedirectResult returns a null user.

This seems like a severe issue as iOS 16.1 will be released next week and presumably this issue will affect all those iOS users.

Notably there seems to be a workaround of using signInWithPopup. It seems to work for us, though it is unclear why.

Relevant Code:

const googleProvider = new GoogleAuthProvider();
signInWithRedirect(getAuth(firebaseApp), googleProvider);

[haydarKarkin]

Hello, today 16.1 version was released, and this problem still continues. Can you help us with this problem, please?

[sam-gc]

Hi folks, we're still diagnosing the particular issues at play, but it appears that signInWithRedirect still works as expected if you update your authDomain parameter in the Firebase app config to match the URL your site is hosted on (this works if you're on Firebase Hosting).

A full write-up of potential mitigations can be found in #6443 (comment)

[mmmulani]

hey thanks for the update.

just to save anyone else reading this some time, while we have the authDomain parameter set up correctly, we do not use Firebase Hosting and thus are still running into this issue. (I tried to follow the mitigations linked but we already have all those configs set up correctly and notably, signInWithRedirect works for us on Firefox.)

[sam-gc]

Yes, sorry I should have noted that that comment was for Firefox, but we believe it may be a similar underlying mechanism that's causing the user not to be populated.

Mitigation 3 from that list does not use signInWithRedirect or signInWithPopup and will get around this issue for you.

You can sign in to the OAuth provider manually, then simply authenticate with Firebase at the end using signInWithCredential(). For example, with Google: https://firebase.google.com/docs/auth/web/google-signin#advanced:-handle-the-sign-in-flow-manually

[david-wolgemuth]

We are also experiencing this error. Using signInWithRedirect vs signInWithPopup did not help, we are seeing the same issue

I believe this is related to this [prematurely] closed issue: #6636

---

Unfortunately the instructions^ for manually signing in only seem to apply to GoogleProvider, which does not pertain to us

[jzxhuang]

Can confirm this is happening on 16.1 Safari, including iOS 16.1. The suggested solutions all have flaws:

1. signInWithPopup does not work on mobile web browsers, you must use signInWithRedirect
2. Firebase Hosting obviously isn't a universal soln, we aren't using Firebase Hosting
3. Authenticating with the OAuth provider sounds plausible, but this removes one of the huge benefits of using Firebase for authentication in the first place. Lots of eng work, having to implement and maintain OAuth flows manually for each supported provider.

Does it look like there are any other solutions in sight? Can we switch to some cookie-based authentication possibly? As 16.1 rolls out this is going to affect a huge number of users. Thanks! cc @sam-gc @prameshj

[bvandersloot-mozilla]

This likely has the same cause as #6443.

[prameshj]

Does it look like there are any other solutions in sight? Can we switch to some cookie-based authentication possibly? As 16.1 rolls out this is going to affect a huge number of users. Thanks!

We are exploring a few options for a longer-term fix. Cookie-based authentication will run into this same limitation since the oauth helper code is in <project>.firebaseapp.com domain (or the firebase hosting domain, if specified in the authDomain parameter). If this domain is different from the domain where the app is running, there is a cross-origin storage access to complete sign in, which gets blocked by some browser policies.

Note that the FirebaseUI Web issue(firebase/firebaseui-web#977) is different and presents with a "TypeError: Right side of assignment cannot be destructured" in the console.

[carlospero]

Curiously on iOS 16.1, Chrome and Firefox and Brave also suffer the same issue as Safari!

signInWithPopup does bypass the problem on all of those browsers too. So, whatever long-term fix is determined, it hopefully applies across all of iOS.

(Latest versions of Chrome and Firefox and Brave on MacOS still function using signInWithRedirect.)

[galaxyblur]

Curiously on iOS 16.1, Chrome and Firefox and Brave also suffer the same issue as Safari!

signInWithPopup does bypass the problem on all of those browsers too. So, whatever long-term fix is determined, it hopefully applies across all of iOS.

(Latest versions of Chrome and Firefox and Brave on MacOS still function using signInWithRedirect.)

There is only one actual browser on iOS: Safari. The other browsers use Safari beneath their own UI/UX.

[bt-akiko]

Hello, is anyone still meet this issue ? since on my environment, I cannot meet in that means reproduce this phenomenon iOS 16.1 and safari with iPhone 14 pro

[bvandersloot-mozilla]

We are exploring a few options for a longer-term fix. Cookie-based authentication will run into this same limitation since the oauth helper code is in .firebaseapp.com domain (or the firebase hosting domain, if specified in the authDomain parameter). If this domain is different from the domain where the app is running, there is a cross-origin storage access to complete sign in, which gets blocked by some browser policies.

@prameshj: If you want a privacy engineer at Mozilla to talk to, I can chat about some of these options!

[deshiknaves]

Now that Safari 16.1 is released, this is affecting users. Are there any manual work arounds (like implementing the party flow not using the SDK) that we could implement?

Also if there is anything I can help with testing, let me know.

[deshiknaves]

Ok. Been doing some digging into this and I can confirm that signInWithPopup works exactly as expected as mentioned above. It was mentioned above that this doesn't work on mobile, this is untrue. It opens up another page where you login and it takes you back to the previous window after they have authed. We have a convoluted setup that is a bit more complex that simple popup on a page, and this was not an issue to implement.

I think the one thing that catches people out when implementing signInWithPopup is that they initiate it in a way that isn't the direct result of a user interaction. Browsers will block popups unless they are created as a direct result of an action from the user. I.e. put it in the click handler and you won't have an issue.

[galaxyblur]

Does signInWithPopup work in native app web views? I have to assume it does not, but maybe someone figured it out.

[Sallaa]

@galaxyblur we have tried to use signInWithPopup with web views for our mobile apps and it did not work for us. However I can also confirm that signInWithPopup was our workaround for the browser.

[jzxhuang]

Ok. Been doing some digging into this and I can confirm that signInWithPopup works exactly as expected as mentioned above. It was mentioned above that this doesn't work on mobile, this is untrue.

Hmm... I'm pretty sure some mobile web browsers, like Chrome iOS, block popups by default, even when they are the result of an action from the user. Or at least there is a setting to do this. Even if that's not the case, there's still other pitfalls: signInWithPopup will not work with in-app web views, and it can fail for a variety of reasons even on desktop — for example an aggresive adblocker.

Our strategy is to try signInWithPopup, and if that fails with error code POPUP_BLOCKED, we fallback to signInWithRedirect. signInWithRedirect is a failsafe that can be invoked for all sorts of odd reasons/edge cases.

From Firebase's Auth docs:

You can prompt your users to sign in with their Google Accounts either by opening a pop-up window or by redirecting to the sign-in page. The redirect method is preferred on mobile devices.

@prameshj, do you or the Firebase team have an estimate/idea of if there is a fix for this in the short term? Any updates are appreciated — if there is no short-term fix on the horizon, our team needs to seriously consider implementing the OAuth providers ourselves, and only using Firebase SDK to get a FIrebase token (suggestion 3 of #6443 (comment)). This is obviously a fairly large resource commitment, so we'd like to know if there's any other possible solutions in the works...

[galaxyblur]

I 2nd that -- knowing whether a fix in possible in the near term would help a great deal.

[mesqueeb]

I also would like to know when a fix is planned.

If it comes to having to re-implement apple/Google/Twitter auth manually via OAuth, maybe this can be shared among the community here so everyone here can benefit from it.

[prameshj]

Hi all, thanks for your patience on this issue.

Are there any manual work arounds (like implementing the party flow not using the SDK) that we could implement?
Also if there is anything I can help with testing, let me know.

In addition to the workarounds listed here, there is the option to self-host the signin helper code.

Here is a flowchart to determine the most suitable mitigation depending on the setup:

Self-Hosting the widgets:

Note: This approach will not work for Apple sign in and SAML. Please use a different mitigation for those.

The signInWithRedirect flow starts by redirecting from your app domain to the
domain specified in the authDomain parameter in firebase config
(".firebaseapp.com" by default). authDomain hosts the sign-in helper
code that redirects to the Identity Provider, which, on success, redirects back
to the app domain.

When authentication flow returns to your app domain, the browser storage of the sign-in helper
domain is accessed. Hosting the helper code in your app domain eliminates the
cross-origin storage access, which otherwise gets blocked by browsers.

Hosting the helper code has the following steps:

1. Download the files to host from the <project>.firebaseapp.com location by
   executing the following commands:

   mkdir signin_helpers/ && cd signin_helpers
   wget https://<project>.firebaseapp.com/__/auth/handler
   wget https://<project>.firebaseapp.com/__/auth/handler.js
   wget https://<project>.firebaseapp.com/__/auth/experiments.js
   wget https://<project>.firebaseapp.com/__/auth/iframe
   wget https://<project>.firebaseapp.com/__/auth/iframe.js
   

2. Host the above files under your app domain. Ensure that your web server can
   respond to https://<app domain>/__/auth/<filename>.

Here is a sample server implementation that downloads and hosts the files - https://go.dev/play/p/qnI8PEPwME6

3. Follow the steps in this comment(option 2) to update authorized redirect_uri and your authDomain.
   Once you redeploy your app, the cross-origin storage access should no longer happen.

[prameshj]

We will document these mitigation options in the official docs and drop a link here soon. We are investigating options for a more permanent solution, however, we do not have an ETA right now.

[samsargent]

Download the files to host from the .firebaseapp.com location by
executing the following commands:

Looks like there is a missing iframe html file from this list as the redirect back also loads /__/auth/iframe?apiKey=...

Also FYI - experiment.js should be experiments.js

mkdir signin_helpers/ && cd signin_helpers
wget https://<project>.firebaseapp.com/__/auth/handler
wget https://<project>.firebaseapp.com/__/auth/handler.js
wget https://<project>.firebaseapp.com/__/auth/experiments.js
wget https://<project>.firebaseapp.com/__/auth/iframe
wget https://<project>.firebaseapp.com/__/auth/iframe.js

[prameshj]

Thanks! fixed.

[lincolnthree]

Download the files to host from the .firebaseapp.com location by
executing the following commands...

Out of curiosity, if we are self-hosting. I wonder if setting up a webserver proxy to these files would be a slightly more long-term/resilient option, rather than downloading and hosting the files directly (and risking them going out of date.)

E.g.: Forwarding https://customdomain.com/__/auth/ -- to --> https://<project>.firebaseapp.com/__/auth

nginx example config:

  location /__/auth {
    # Firebase Auth Helper Proxy Forwarding Config

    allow all;

    proxy_http_version      1.1;
    proxy_pass              https://<project>.firebaseapp.com;
  }

If so, additionally, I wonder if this is something that might be added as an optional firebase configuration anyway (thus removing the need for the <project>.firebaseapp.com domain redirect entirely?

EDIT: On further inspection, I see that's what your example server script is essentially doing. And I've now verified this and it works.

[prameshj]

Hi @lincolnthree , you are right.. Setting up a reverse proxy on your app domain to route "/auth" requests to https://.firebaseapp.com//auth would be a more resilient and elegant solution. Thanks!

You're right.. the example script does almost the same thing, but it does cache the files locally, but can be modified to sync the files periodically or proxy to the https://<project>.firebaseapp.com destination.

[sww314]

@prameshj
Is there a work around for SAML? This is the flow we care about.
As others have mentioned the signInWithPopup does not work on mobile. Native app webviews typically block the popups.

[prameshj]

The list of mitigations have been published at https://firebase.google.com/docs/auth/web/third-party-storage-mitigation

Is there a work around for SAML? This is the flow we care about.

@sww314 if you are not on Firebase Hosting, then https://firebase.google.com/docs/auth/web/third-party-storage-mitigation#mitigation_3_proxy_auth_requests_to_firebaseappcom should work.

[HoshenIshay]

I have a similar problem
Firebase authentication for an Angular application is not working on iOS version 16
Users who have updated to IOS 16 are unable to log in to the system using a Google account,
whereas users with previous versions can still log in without any issues.

[SamLoy]

I was stuck with the same issue. Performing the 'redirect' firebaseui login Facebook login failed on iOS16 both in Safari and through the Facebook WebView.

As stated above, option 2 here worked for me: #6443 (comment)

[dcoleyoung]

Would it be possible to add an example to the documentation for how to do a reverse proxy in Flask, as we run on app engine on custom domain? for mitigation Option 3: Proxy auth requests to firebaseapp.com

[klemola]

I believe this should be fixed in Firebase Authentication itself. It should not rely on cross-domain session storage, and I'm astonished that this has been considered a valid solution in the first place.

The reverse proxy works, but may require extra work if you have a solid CSP.

For instance, for the reverse proxy to work with safe and XSS resistant script-src policy (that is, no unsafe-inline), one has to add the <redacted, outdated advice to calculate hashes for the inline scripts>.

See @prameshj 's replies below for a CSP-friendly solution with nonce

You might also need to update the default-src / frame-ancestors / script-src policies to include Firebase auth domain.

[prameshj]

So, for those stuck with CSP issues, this might help:

Add the following to script-src policy: 'sha256-4Sry3sxnDNx0KfLx6AAUo8D2CUTWL64/sHuxb6HhCaM=' 'sha256-LhIWOhjLqan1vNuJevmXgr6L87Nor5PqfWzSqz9q74w='

That is the hash for the two inline scripts as of 2023-03-02

Hi folks, thanks for pointing out this workaround. However, we do not recommend this approach since the script contents might change anytime.

We will add a nonce to the inline script so that can be used as described in https://content-security-policy.com/examples/allow-inline-script/, so it will be a more stable value that can be allowlisted. I will update this thread once we roll this out.

We are working on removing the inline js and will use #5193 to track this.

[klemola]

@prameshj Thank you for the quick response. A nonce is a fair solution, and I'm glad to hear that the inline JS is being removed. This will make the issue much less painful on our end.

I'll update my message to remove the workaround once the nonce is live (to avoid confusion).

[prameshj]

Ever since proxying the iframe requests to our custom domain to solve this issue, we receive the following in the console whenever there is an initial authentication attempt. Everything works in the app but these error keeps appearing. The "bnith" URL request works every request after and only appears one time. The Fingerprint JS will happen every first load only as well. The FingerprintJS error mentions the "customdomain.com/__/auth/iframe?apiKey=...." path.

Any ideas regarding this issue is greatly appreciated. Thank you.

Is Fingerprint JS a service like described in https://blog.khophi.co/getting-started-with-fingerprintjs-pro/? I wonder if the error is just saying that __/auth/iframe code is not hosted in customdomain.com (but it at .firebaseapp.com) and is flagging that as potentially malicious. Is there a way to allowlist this URL path?

[prameshj]

@prameshj Thank you for the quick response. A nonce is a fair solution, and I'm glad to hear that the inline JS is being removed. This will make the issue much less painful on our end.

I'll update my message to remove the workaround once the nonce is live (to avoid confusion).

Thanks @klemola .. you should now see a nonce around the inline JS in auth/handler and auth/iframe.

<script type="text/javascript" nonce="firebase-auth-helper">
var POST_BODY = '{{POST_BODY}}';
fireauth.oauthhelper.widget.initialize();
</script>

[prameshj]

Is Fingerprint JS a service like described in https://blog.khophi.co/getting-started-with-fingerprintjs-pro/? I wonder if the error is just saying that __/auth/iframe code is not hosted in customdomain.com (but it at .firebaseapp.com) and is flagging that as potentially malicious. Is there a way to allowlist this URL path?

Thanks for the response @prameshj - Fingerprint JS is not something we are using in our app. It appears to be part of Google's Firebase auth flow via the SDK? It doesn't exist in our project itself.

the "getClientIdentity" in the stacktrace isn't coming from the auth sdk or the auth helpers... Do you have more info on where that code is from?

[logason]

Thanks @klemola .. you should now see a nonce around the inline JS in auth/handler and auth/iframe.

<script type="text/javascript" nonce="firebase-auth-helper">
var POST_BODY = '{{POST_BODY}}';
fireauth.oauthhelper.widget.initialize();
</script>

It seems like this change caused our CSP to start blocking Firebase Google login on our site. We already had nonce configured, and injected to every script tag on the page through Nginx. Here's the error when we try to login via Google:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-<redacted>"' 'strict-dynamic' https://...<redacted>". Either the 'unsafe-inline' keyword, a hash ('sha256-<redacted>"'), or a nonce ('nonce-...') is required to enable inline execution.

When looking at the inline js tags the Firebase SDK pulls in, one of them now has two nonce, one from our Nginx and one nonce="firebase-auth-helper":

<script nonce="<redacted>" type="text/javascript" src="iframe.js"></script>
<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

Any ideas how to work around this @prameshj? This starting failing few hours ago, sounds like that was around a similar time the nonce="firebase-auth-helper" was added.

[prameshj]

Thanks Matias Klemola .. you should now see a nonce around the inline JS in auth/handler and auth/iframe.

<script type="text/javascript" nonce="firebase-auth-helper">
var POST_BODY = '{{POST_BODY}}';
fireauth.oauthhelper.widget.initialize();
</script>

It seems like this change caused our CSP to start blocking Firebase Google login on our site. We already had nonce configured, and injected to every script tag on the page through Nginx. Here's the error when we try to login via Google:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-<redacted>"' 'strict-dynamic' https://...<redacted>". Either the 'unsafe-inline' keyword, a hash ('sha256-<redacted>"'), or a nonce ('nonce-...') is required to enable inline execution.

When looking at the inline js tags the Firebase SDK pulls in, one of them now has two nonce, one from our Nginx and one nonce="firebase-auth-helper":

<script nonce="<redacted>" type="text/javascript" src="iframe.js"></script>
<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

Any ideas how to work around this @prameshj? This starting failing few hours ago, sounds like that was around a similar time the nonce="firebase-auth-helper" was added.

Are you able to use the "firebase-auth-helper" nonce instead of the dynamically generated nginx nonce? Or can you allowlist "firebase-auth-helper" as an accepted nonce? I believe this would be in the "add-header" section of the nginx config. Like add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-firebase-auth-helper';";

[logason]

Are you able to use the "firebase-auth-helper" nonce instead of the dynamically generated nginx nonce? Or can you allowlist "firebase-auth-helper" as an accepted nonce? I believe this would be in the "add-header" section of the nginx config. Like add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-firebase-auth-helper';";

I think the main problem for me right now is that the script tag has two nonce, I assume that won't work. Currently figuring out how I can get Nginx to not inject a nonce for that particular script tag. Right now we're using a very simple sub_filter to inject the nonce: sub_filter '<script' '<script nonce="$cspNonce"';

Resulting in two nonce on this element:

<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

[prameshj]

Are you able to use the "firebase-auth-helper" nonce instead of the dynamically generated nginx nonce? Or can you allowlist "firebase-auth-helper" as an accepted nonce? I believe this would be in the "add-header" section of the nginx config. Like add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-firebase-auth-helper';";

I think the main problem for me right now is that the script tag has two nonce, I assume that won't work. Currently figuring out how I can get Nginx to not inject a nonce for that particular script tag. Right now we're using a very simple sub_filter to inject the nonce: sub_filter '<script' '<script nonce="$cspNonce"';

Resulting in two nonce on this element:

<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

You could modify the filter to replace nonce="firebase-auth-helper" with `nonce="$cspNonce"'

[logason]

Are you able to use the "firebase-auth-helper" nonce instead of the dynamically generated nginx nonce? Or can you allowlist "firebase-auth-helper" as an accepted nonce? I believe this would be in the "add-header" section of the nginx config. Like add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-firebase-auth-helper';";

I think the main problem for me right now is that the script tag has two nonce, I assume that won't work. Currently figuring out how I can get Nginx to not inject a nonce for that particular script tag. Right now we're using a very simple sub_filter to inject the nonce: sub_filter '<script' '<script nonce="$cspNonce"';
Resulting in two nonce on this element:

<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

You could modify the filter to replace nonce="firebase-auth-helper" with `nonce="$cspNonce"'

Removing the nonce="firebase-auth-helper" resolved the issue for us, with this filter:

sub_filter 'nonce="firebase-auth-helper"' '';

Why was that nonce being added in the first place? 🤔

[prameshj]

Are you able to use the "firebase-auth-helper" nonce instead of the dynamically generated nginx nonce? Or can you allowlist "firebase-auth-helper" as an accepted nonce? I believe this would be in the "add-header" section of the nginx config. Like add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-firebase-auth-helper';";

I think the main problem for me right now is that the script tag has two nonce, I assume that won't work. Currently figuring out how I can get Nginx to not inject a nonce for that particular script tag. Right now we're using a very simple sub_filter to inject the nonce: sub_filter '<script' '<script nonce="$cspNonce"';
Resulting in two nonce on this element:

<script nonce="<redacted>" type="text/javascript" nonce="firebase-auth-helper">

You could modify the filter to replace nonce="firebase-auth-helper" with `nonce="$cspNonce"'

Removing the nonce="firebase-auth-helper" resolved the issue for us, with this filter:

sub_filter 'nonce="firebase-auth-helper"' '';

Why was that nonce being added in the first place? 🤔

See #6716 (comment)

[m-rahme]

Hi @prameshj, everyone,

I followed [Option #4] (https://firebase.google.com/docs/auth/web/redirect-best-practices#self-host-helper-code) but still wasn’t able to actually run the code in the handler file at “myappdomain/__/auth/handler”. It’s always downloading the handler file instead of executing it.

The other options are not feasible for me since my hosting is done on cloudfront and a pop up won’t be optimal for my users.

I must be missing something. Do you have an idea on what might be happening?

[prameshj]

Hi @prameshj, everyone,

I followed [Option #4] (https://firebase.google.com/docs/auth/web/redirect-best-practices#self-host-helper-code) but still wasn’t able to actually run the code in the handler file at “myappdomain/__/auth/handler”. It’s always downloading the handler file instead of executing it.

The other options are not feasible for me since my hosting is done on cloudfront and a pop up won’t be optimal for my users.

I must be missing something. Do you have an idea on what might be happening?

Can you ensure that calls to GET “myappdomain/__/auth/handler” are returning html back? This will look similar to

<!DOCTYPE html>
<html>
<head>
<meta name=viewport content="width=device-width, initial-scale=1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript" src="experiments.js"></script>
<script type="text/javascript" src="handler.js"></script>
...
...

You can create an HAR file in the browser to ensure the calls to download handler, followed by handler.js, experiment.js are all being issued.

[m-rahme]

Fixed @prameshj

[CaptainDingle]

Is Fingerprint JS a service like described in https://blog.khophi.co/getting-started-with-fingerprintjs-pro/? I wonder if the error is just saying that __/auth/iframe code is not hosted in customdomain.com (but it at .firebaseapp.com) and is flagging that as potentially malicious. Is there a way to allowlist this URL path?

Thanks for the response @prameshj - Fingerprint JS is not something we are using in our app. It appears to be part of Google's Firebase auth flow via the SDK? It doesn't exist in our project itself.

the "getClientIdentity" in the stacktrace isn't coming from the auth sdk or the auth helpers... Do you have more info on where that code is from?

We found that this actually had nothing to do with Firebase or this open issue at all. The error and code injection was caused by our web application firewall. We just happen to notice it at the time we added the Firebase proxy to work around this open issue and drew an incorrect conclusion. Thank you.

[prameshj]

Is Fingerprint JS a service like described in https://blog.khophi.co/getting-started-with-fingerprintjs-pro/? I wonder if the error is just saying that __/auth/iframe code is not hosted in customdomain.com (but it at .firebaseapp.com) and is flagging that as potentially malicious. Is there a way to allowlist this URL path?

Thanks for the response @prameshj - Fingerprint JS is not something we are using in our app. It appears to be part of Google's Firebase auth flow via the SDK? It doesn't exist in our project itself.

the "getClientIdentity" in the stacktrace isn't coming from the auth sdk or the auth helpers... Do you have more info on where that code is from?

We found that this actually had nothing to do with Firebase or this open issue at all. The error and code injection was caused by our web application firewall. We just happen to notice it at the time we added the Firebase proxy to work around this open issue and drew an incorrect conclusion. Thank you.

Thank you so much for closing the loop here!

[prameshj]

Closing this issue since following the best practices at https://firebase.google.com/docs/auth/web/redirect-best-practices fixes this.

[ahetawal-p]

I am having similar issues like this comment here: #6716 (comment)
The handler and iframe files are being downloaded from browser instead of being rendered.
I am using nextjs + vercel to deploy my app, and really not sure how do I proceed. ?

[tycrimm]

I am having similar issues like this comment here: #6716 (comment) The handler and iframe files are being downloaded from browser instead of being rendered. I am using nextjs + vercel to deploy my app, and really not sure how do I proceed. ?

Adding the following rewrite to vercel.json and updating the authorized domains/redirect_urls in the GCP Console makes the approach of proxying requests viable for a Vercel deployment:

{
  ...,
  "rewrites": [
    {
      "source": "/__/auth/(.*)",
      "destination": "https://YOUR_APP_ID.firebaseapp.com/__/auth/$1"
    },
  ],
  ...
}