verifyPhoneNumber errors with auth/invalid-app-credential only on localhost

[MaciejCaputa]

Operating System

macOS Sonoma 14.2.1

Browser Version

Chrome 126.0.6478.183

Firebase SDK Version

10.12.4

Firebase SDK Product:

AppCheck, Auth

Describe your project's tooling

Next.js using firebase app check with reCAPTCHA Enterprise with configured debug app check token

Describe the problem

On localhost verifyPhoneNumber calls following endpoint

https://identitytoolkit.googleapis.com/v2/accounts/mfaSignIn:start?key=<api-key>

which returns

{
  "error": {
    "code": 400,
    "message": "INVALID_APP_CREDENTIAL",
    "status": "INVALID_ARGUMENT"
  }
}

Steps and code to reproduce issue

1. Call verifyPhoneNumber in multifactor authentication flow on localhost

Important facts

• Interestingly,verifyPhoneNumber work perfectly fine, but stopped working couple of days ago only when developing locally on localhost
• The deployed (hosted on Vercel) even after redeployment continue to work just fine
• Similar issue reported here https://www.reddit.com/r/Firebase/comments/1e8pdcf/firebase_error_authinvalidappcredentials_in/

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[odina101]

firebase has issue on its servers

[shahsagarm]

I'm also facing the same exact issue. It suddenly stopped working locally but on deployed version (vercel) it works fine with same firebase config.

[MaciejCaputa]

firebase has issue on its servers

Do they know they have an issue? Are they working on the fix? Is there a ticket we can track?

[ricardodebeijer]

We are also having this issue, with a Ionic Cordova app, since past friday.
We have a P1 ticket opened at GCP support currently.

[Sam-Persoon]

We also have a ticket opened at GCP. For those that want a temporary workaround, you can serve on 127.0.0.1 instead of localhost and add 127.0.0.1 in Firebase console -> authentication -> settings -> authorised domains.

[MaciejCaputa]

We also have a ticket opened at GCP. For those that want a temporary workaround, you can serve on 127.0.0.1 instead of localhost and add 127.0.0.1 in Firebase console -> authentication -> settings -> authorised domains.

I tried 127.0.0.1 and added it as an authorized domain, but it didn't work for me. Perhaps it is because we use reCaptcha Enterprise where we don't have whitelisted 127.0.0.1

[LizDodion]

Also seeing this

I added 127.0.0.1 as an authorised domain and switched our app to do that and it worked fine

Would be great if firebase can fix asap as we have a lot of other apps that need to be reconfigured and don't want to have to add everywhere

[jbalidiong]

Hi @MaciejCaputa, thanks for reaching out to us. I was able to replicate the behavior. Let me check what we can do for this issue with our Auth team or bring someone here that can provide more context about it. I’ll update this thread if I have any information to share.

[deepakrh185]

I'm encountering the same issue in my React project. It seems to only occur in the web app, while it works fine on mobile.

[saharvx9]

Working only for test numbers, i am getting this error too in flutter with "signInWithPhoneNumber"

[Sumit-Mayani]

I'm encountering the same issue in my React project. It seems to only occur in the web app, while it works fine on mobile.

its working in mobile correctly but issue face only on web

[Sumit-Mayani]

We also have a ticket opened at GCP. For those that want a temporary workaround, you can serve on 127.0.0.1 instead of localhost and add 127.0.0.1 in Firebase console -> authentication -> settings -> authorised domains.

not working

[ansh]

I'm having this issue as well on a NextJS 14 app using app router. Other authentication mechanisms work, like anonymous auth and email auth.

[yeonjoonkim]

Hi I am having same problem with phone authentication on localhost.

I have included localhost and 127.0.0.1 into firebase console and google cloud

1. Firebase Console => Authentication => Setting => Approved Domain

• localhost
• 127.0.0.1

2. Google Cloud => Project => Credential => OAuth 2.0 Client ID => Authroised Javascript ...

• http://localhost
• https://localhost
• http://127.0.0.1
• https://127.0.0.1
• https://localhost:8100
• https://localhost:8101
• https://localhost:5000

Error Code

https://identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode?key=${key}
Request method: Post
Access-Control-Allow-Origin: http:localhost:8100

Response: {
  "error": {
    "code": 400,
    "message": "INVALID_APP_CREDENTIAL",
    "errors": [
      {
        "message": "INVALID_APP_CREDENTIAL",
        "domain": "global",
        "reason": "invalid"
      }
    ]
  }
}

Environment

package

    "@angular/animations": "^18.1.1",
    "@angular/cdk": "^18.1.1",
    "@angular/common": "^18.1.1",
    "@angular/core": "^18.1.1",
    "@angular/fire": "^18.0.1",
    "@angular/forms": "^18.1.1",
    "@angular/localize": "^18.1.1",
    "@angular/platform-browser": "^18.1.1",
    "@angular/platform-browser-dynamic": "^18.1.1",
    "@angular/router": "^18.1.1",
    "@angular/service-worker": "^18.1.1",
    "firebase": "10.12.4",

Phone Authentication Code

  public async sendOTP(ph: string): Promise<void> {
    try {
      this.registerRecaptchaDiv();
      const verificationId = await this.getVerificationId(ph);
      this.phoneCodeSentEvent$.next(verificationId);
    } catch (error) {
      this.errorMsg$.next(getErrorMsg(error));
    }
  }
  
    public async confirmOTP(verificationId: string, verificationCode: string): Promise<void> {
    try {
      const authCredential = PhoneAuthProvider.credential(verificationId, verificationCode);
      const userCredential = await signInWithCredential(this.auth, authCredential);

      this.signInResult$.next(userCredential?.user ?? null);
    } catch (error) {
      this.errorMsg$.next(getErrorMsg(error));
    }
  }
    
    private registerRecaptchaDiv() {
    const recaptchContainer = document.getElementById('recaptcha-container');

    if (recaptchContainer) {
      const parent = recaptchContainer.parentNode;
      parent?.removeChild(recaptchContainer);

      const newRecaptchContainer = document.createElement('div');
      newRecaptchContainer.id = 'recaptcha-container';
      parent?.appendChild(newRecaptchContainer);
    }
  }
  
  
    private getVerificationId(ph: string) {
    const appVerifier = new RecaptchaVerifier(this.auth, 'recaptcha-container', {
      size: 'invisible',
      callback: (response: any) => {
        console.log('Recaptcha verified');
      },
    });

    const provider = new PhoneAuthProvider(this.auth);
    const verificationId = provider.verifyPhoneNumber(ph, appVerifier);
    appVerifier.clear();
    return verificationId;
  }
  

[diffractometer]

+1 seeing this issue a lot lately

[DellaBitta]

Hi all,

This error is due a change in Auth Service policy which no longer supports localhost for verifyPhoneNumber invocations. The new guidance is part of our documentation here.

The Auth team has suggested the use of fictional phone numbers for testing purposes.

I'm going to remove the bug label from this issue but I'll leave it open for any questions that may arise. Thanks.

[NhienLam]

Hi @aem, for local development testing, you should be able to use configured fictional phone numbers or Auth Emulator. Additionally, you can use 127.0.0.1 to test as mentioned above.

This is occurring even when using the configured test phone numbers.

You won't see auth/invalid-app-credential error when using the configured fictional phone number.

[aem]

I've been using fictional phone numbers and they do not work, I get the same error.

Observe, the phone number I'm sending with my verification request:

Properly configured as a test phone number for SMS:

But still produces auth/invalid-app-credential when I call verifyPhoneNumber

[NhienLam]

@aem that's odd. We verified that using fictional phone numbers worked.

1. Could you try sending the request with "+15555555555" instead of "+1 555-555-5555"?
2. Could you make sure you configured the fictional phone number in the correct project that you were testing?

[touy]

Hi everyone,

We implemented a change to disallow Phone Auth from localhost to address a potential vulnerability that could have led to exploitation. While we recognize this change may have unintended consequences from some developers, we cannot rollback the fix due to the security risk it poses.

Impacted project owners will receive communication on next steps soon. We apologize for any inconvenience this has caused.

oh, this is a bad dream all ionic project use a webview with localhost , so all ionic capacitor would be a trash , I have checked my website could work well with a proper domain , but it could not work for ionic capacitor project , that is a bad dream

[rscotten]

@NhienLam Why is it that 127.0.01 is allowed but localhost isn't? Wouldn't they have the same security vulnerabilities?

Also, whoever rolled out this update could have saved thousands of developers many hours just by having a more informative error message like localhost is no longer allowed for Multi Factor phone authentication. Use 127.0.0.1 instead. Read more (link).

If Google/Firebase actually cares about their users, they should really consider the economic cost of bad error messages like this before rolling them out unannounced.

[kondricz]

Hello,

Anyone else having this issue coming up in a hosted environment?

I have not found a pattern yet, but the error is showing up in our systems even when deployed. I have not found a reproducable pattern yet, but some of our developers are facing this issue regularly, especially in in-app browsers (like browser from instagram, browser from telegram).

We use nextJS.

[MaciejCaputa]

Hello,

Anyone else having this issue coming up in a hosted environment?

I have not found a pattern yet, but the error is showing up in our systems even when deployed. I have not found a reproducable pattern yet, but some of our developers are facing this issue regularly, especially in in-app browsers (like browser from instagram, browser from telegram).

We use nextJS.

We also use NextJS and experience that on products sometimes (15% of times) SMS codes are not delivered. We have not yet verified if it is because of this issue, or another issue, but I can't imagine mobile carriers loosing around 15% of SMS.

Can anybody advise how we can report it?

[touy]

@NhienLam Why is it that 127.0.01 is allowed but localhost isn't? Wouldn't they have the same security vulnerabilities?

Also, whoever rolled out this update could have saved thousands of developers many hours just by having a more informative error message like localhost is no longer allowed for Multi Factor phone authentication. Use 127.0.0.1 instead. Read more (link).

If Google/Firebase actually cares about their users, they should really consider the economic cost of bad error messages like this before rolling them out unannounced.

ionic capacitor or any hybrid app is dead now , customers complained and just wait for this issue to be fixed soon

[trauma-and-drama]

It is beyond my belief that Google just changes these things unilaterally without proper communication / documentation.
Aside of the 'localhost' issue we are experiencing from a good number of users with that same error on production.
Suddently without touching the code.

The only solution for us now is to throw out this gcp auth garbage and do our own flows.
Google developers need to understand that such breaking changes or whatever this is are hurting mission critical projects.
And there is no room for slack for us.

[gvillaume]

For anyone using ionic capacitor, the localhost issue can be fixed in production by updating the server hostname in your capacitor.config.ts file.

Ex.

const config: CapacitorConfig = {
...
  server: {
    hostname: 'my-app.com',
    androidScheme: 'https',
  }
};

Here's the documentation: https://capacitorjs.com/docs/guides/autofill-credentials#set-capacitor-server-hostname

[diffractometer]

+1 seeing this in production a fair amount auth/invalid-app-credential cc @kondricz

[kondricz]

Hey everyone,

Did Google rolled back this update? I just tested it now (with non-testing real number) on localhost, and it is working again finally.

[LizDodion]

It started working back again for me today after not working for a few weeks. hopefully it is now rolled back

[trauma-and-drama]

It started working back again for me today after not working for a few weeks. hopefully it is now rolled back

I can't confirm this. After performing the recaptcha, the error is still appearing for localhost and unclear if it still appears in production. Waiting on client feedback.

ERROR 1: identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode?key=:1 httperror 400 Failed to load resource: the requested URL /v1/accounts:sendVerificationCode?key= was not found on this server.
ERROR 2: recaptcha__en.js:249 Uncaught TypeError: Cannot read properties of null (reading 'style')

firebase_core: ^2.25.4
firebase_auth: ^4.17.4

doesn't work with
firebase_core: ^3.3.0
firebase_auth: ^5.1.4
either

[kondricz]

I think they are working on it right now. Can someone confirm this from google team?

I had 5 sign ups and it was also working from localhost, but now the error is appearing again. This is VERY BAD. Why can't we just roll it back and release it only when its properly tested and won't break all of our stuff ?

[mohsenkhkh]

We also have a ticket opened at GCP. For those that want a temporary workaround, you can serve on 127.0.0.1 instead of localhost and add 127.0.0.1 in Firebase console -> authentication -> settings -> authorised domains.

I tried 127.0.0.1 and added it as an authorized domain, but it didn't work for me. Perhaps it is because we use reCaptcha Enterprise where we don't have whitelisted 127.0.0.1

did you place 127.0.0.1 instead of localhost in your browser too? that was for me 127.0.0.1:3000 instead of localhost:3000

[kondricz]

Any updates here? Our team is still suffering from this.

We are considering just to build this thing on our own or use another provider.

[trauma-and-drama]

There seems to be an issue not only with localhost, but potentially proxy or NAT-based networks (can't tell).

We pulled the plug and deployed a custom Phone-Auth via Twillio, Firebase https-Functions, and customTokens.
This whole handshake with recaptcha is just too buggy and blackboxy for us, the settings page for recaptcha does not seem to be well integrated. And the support here, is mindboggingly absent on a critical issue like this (3 weeks!!)

My advice to the Google Firebase/GCP team:
If you want small businesses to use your services, take more care on breaking changes.
The world is more complex beyond your Google cubicle (this is me being nice and mindful).

[kondricz]

It is funny for me.

It feels like the team is constantly working on the issue, but they sort of pushing on prod and let us end users test it 😭

Sometimes it works flawlessly for hours or even half a day (I guess this is the time when they restore the older version of the API), then it randomly starts failing for few hours.

Yesterday we had around 100 phone registration and 5 of them failed with this. Is there anyone here who has not migrated to their own solution yet and experiencing the same?

[kyleabens]

When did this change from localhost come into effect? Is there a version of firebase we can roll back to?

[touy]

I can solve the problem by doing these

1. server-side Nodejs
   using version: "firebase-admin": "^12.2.0",

2. Client-side ionic capacitor:
   verifyPhoneNumber errors with auth/invalid-app-credential only on localhost #8387 (comment)

3. and client code ionic capacitor:
   using version: "firebase": "^9.23.0",

and you can keep your old codes and it could work normally

client-side firebase from npm changed completely and it needs to change a lot of works , this is the shortest way I have found

[kyleabens]

I can solve the problem by doing these

1. server-side Nodejs
   using version: "firebase-admin": "^12.2.0",
2. Client-side ionic capacitor:
   verifyPhoneNumber errors with auth/invalid-app-credential only on localhost #8387 (comment)
3. and client code ionic capacitor:
   using version: "firebase": "^9.23.0",

and you can keep your old codes and it could work normally

client-side firebase from npm changed completely and it needs to change a lot of works , this is the shortest way I have found

This does work but changing the hostname in capacitor.config can lead to a lot of other issues for Android, just FYI. I changed the hostname to 127.0.0.1 for the time being for 2FA to work again

[AkshayThota7747]

For local testing, use 127.0.0.1 and allow the same in authorized domain. It worked for me and it's always for me in the production. I was facing the issue only in the local environment

[rajeshpal53]

IP> @NhienLam Why is it that 127.0.01 is allowed but localhost isn't? Wouldn't they have the same security vulnerabilities?

Also, whoever rolled out this update could have saved thousands of developers many hours just by having a more informative error message like localhost is no longer allowed for Multi Factor phone authentication. Use 127.0.0.1 instead. Read more (link).

If Google/Firebase actually cares about their users, they should really consider the economic cost of bad error messages like this before rolling them out unannounced.

You are right , its working with other ips but not by localhost, i wasted 1 week to find solutions and enable every possible solution to fix this, and its currently working with just change by localhost to any IP

[rajeshpal53]

Any updates here? Our team is still suffering from this.

We are considering just to build this thing on our own or use another provider.

use any IP instead of localhost

[Gabe1203]

Has anyone been able to fix this issue on a hosted site? Our local works just fine with a test number but in our hosted site in production (hosted on cloudfront) we can no longer get into the site which is very alarming. We haven't made any updates to the login flow on our site.

[NMann]

Is there any update on this issue, as I am still facing this issue

[wernerkotze]

I've also been a recent victim of this issue, probably wasted about 10 hours of my life. If only AI could solve issues like these 😅

Step 1: use 127.0.0.1:3000 instead of locahost:3000.
Step 2: authorize the domain 127.0.0.1 on your Firebase console.