How Did We Encounter the Firebase Phone Authentication Failure?

While working on a large-scale mobility and fleet management platform, we transitioned the application to Google Play Closed Testing to validate production deployment flows. The application, built with React Native and compiled via cloud CI/CD pipelines, relied heavily on OTP verification for driver onboarding. Everything worked flawlessly in local development and with test phone numbers.

However, when real drivers attempted to log in using live phone numbers, the SMS OTPs were never delivered. We encountered a situation where the authentication pipeline collapsed silently on the front end, while the backend logs revealed a critical integrity check failure. This is a common hurdle when moving from local debug builds to Google Play App Signing environments, where the cryptographic identity of the application changes.

Because reliable onboarding is non-negotiable for enterprise logistics systems, resolving this bottleneck became our immediate priority. This challenge inspired the article so others can avoid the same mistake when configuring firebase phone authentication for production environments.

Why Does App Integrity Matter in Modern Architecture?

In modern mobile architectures, backend services must verify that API requests originate from an untampered, genuine version of your application. Google enforces this through the Play Integrity API and Firebase Authentication to prevent SMS toll fraud, automated bot registrations and unauthorized API consumption.

When an Android application requests an SMS verification code, Firebase SDK interfaces with Google Play services to generate a play_integrity_token. This token proves the app’s legitimacy. The Firebase backend then matches the token against the cryptographic fingerprints (SHA-1 and SHA-256) registered in the Firebase Console. If there is a mismatch, the infrastructure rejects the request to protect your Firebase billing quota from abuse.

For organizations looking to scale, resolving these identity mismatch issues efficiently is exactly why technical leaders choose to hire software developer teams with deep experience in DevOps and release management.

What Caused the “No Matching SHA-256” Error in Production?

Upon reviewing the Android Logcat outputs from a connected production device, we isolated the exact failure point. The Google Services layer was throwing a specific exception:

[SmsRetrieverHelper] SMS verification code request failed: unknown status code: 17028
A play_integrity_token was passed, but no matching SHA-256 was registered in the Firebase console. Please make sure that this application's packageName/SHA256 pair is registered in the Firebase Console.

The fallback callbacks fired subsequently, outputting:

error - This app is not authorized to use Firebase Authentication. Please verify that the correct package name, SHA-1 and SHA-256 are configured in the Firebase Console.The application package name was fully correct and the Blaze plan was active. We had also correctly linked the Play Integrity API project. The symptoms pointed to a severe disconnect between the Google Play App Signing key and the underlying Google Cloud OAuth 2.0 clients auto-generated by Firebase, a notoriously opaque layer of the Google Cloud ecosystem.

How Did We Diagnose the Status Code 17028 Issue?

To identify the root cause, we systematically validated the authentication architecture. We considered these solutions as well during our debugging phase:

Could it be an App Check Enforcement Issue?

Our initial hypothesis was that Firebase App Check was aggressively rejecting the Play Integrity tokens. We checked the Firebase App Check dashboard and verified that Authentication was set to “Unenforced”. Since enforcement was off, App Check was strictly monitoring traffic but not blocking it, ruling this out as the primary cause.

Were API Key Restrictions Blocking the Request?

We then evaluated the Google Cloud Console credentials. We attempted to add Android application restrictions (package name plus SHA-1) to the primary auto-generated Android API key. However, this immediately triggered a different error: Requests from this Android client application are blocked. 403. We realized that modifying API key restrictions on a misconfigured SHA ecosystem only compounds the problem, so we reverted the key restriction back to “None” to isolate the original 17028 error.

Was the Upload Key Mistaken for the Production Key?

Since the app was built using a cloud build system, it was initially signed with an upload key. We verified that we were not mistakenly copying the upload key’s SHA fingerprints into Firebase. We navigated to Play Console, under App Integrity and ensured we were pulling the SHA-1 and SHA-256 explicitly from the “Classical key” under the App Signing key certificate, avoiding the post-quantum keys.

Did We Have Corrupted OAuth Clients Due to Orphaned SHAs?

This led us to the actual architectural flaw. Over the course of development and initial troubleshooting, multiple developers had added various SHA-1 and SHA-256 certificates to the Firebase Console. There were four SHA-1 entries and three SHA-256 entries registered for the Android app. Every time a SHA is added to Firebase, it automatically generates a corresponding OAuth 2.0 Client ID in the Google Cloud Platform (GCP). Having multiple overlapping signatures for the same package name created an identity conflict within the GCP Identity Toolkit layer, causing the token validation to fail even when the correct SHA-256 was technically present in the list.

How Did We Fix the Firebase Phone Auth Android Issue?

To restore functionality to firebase phone auth android services, we executed a complete clean-up and realignment of the cryptographic configuration across Google Cloud, Firebase and our build pipeline.

Step 1: Clean Up Cryptographic Fingerprints

We navigated to the Firebase Console and aggressively deleted every single SHA-1 and SHA-256 entry under the Android app settings. We then manually added back only the verified pair:

• The SHA-1 from the Google Play Console (Classical App Signing Key)
• The SHA-256 from the Google Play Console (Classical App Signing Key)

Step 2: Realign Google Cloud OAuth Clients

We logged into the Google Cloud Console associated with the Firebase project. Under APIs & Services > Credentials, we reviewed the auto-generated “Android client” OAuth 2.0 Client IDs. We deleted any orphaned OAuth clients that referenced the old, deleted SHA certificates to ensure the Identity Toolkit would only evaluate against the single, correct Play Store signature.

Step 3: Update the JSON Configuration

A critical misstep many teams make is assuming backend changes propagate automatically to the client. Because the OAuth client registry was modified, we had to download a fresh google-services.json file from the Firebase Console. We injected this updated configuration file into our CI/CD pipeline environment variables.

Step 4: Rebuild and Distribute

We triggered a new production build through our cloud build system and promoted the new artifact to the Google Play Closed Testing track. Once the Play Store processed the update, we downloaded the app to a physical device.

The result? The SMSOTP fired immediately. The 17028 error was eliminated because the Play Integrity token finally mapped to a clean, singular OAuth 2.0 client matching the Google Play App Signing key.

This level of rigorous pipeline configuration is a primary reason why enterprises choose to hire app developer to create a mobile app that guarantees high availability and secure user onboarding.

What Are the Key Lessons for Engineering Teams?

Resolving this identity mismatch highlighted several crucial takeaways for teams configuring CI/CD and authentication flows:

• Less is More with SHA Certificates: Do not clutter your Firebase configuration with historical debug or upload keys once you move to production. Multiple keys can create conflicting OAuth clients in GCP.
• Play App Signing Alters Your APK: Remember that the APK you build and upload is NOT the APK served to your users. Google Play re-signs it. Always use the App Signing certificate from the Play Console for backend integrations, not your local keystore.
• Configuration is Not Dynamic: Changing SHA fingerprints in Firebase requires downloading a new google-services.json and rebuilding the app. The client must bundle the correct configurations to communicate with the updated Google Cloud APIs.
• Avoid Premature API Restrictions: When debugging authentication pipelines, remove Android application API key restrictions first. Reapply them only after the core integration is verified to avoid confusing 403 errors with token validation errors.
• Play Integrity API requires Time: Linking Play Integrity API and updating GCP credentials can take several hours to propagate globally. Plan your deployment testing accordingly.

Conclusion and Next Steps for Your Team

Diagnosing and fixing the status code 17028 error in Firebase requires looking beyond the Firebase dashboard and understanding how Google Cloud Platform translates those credentials into OAuth clients. By maintaining a strict, clean registry of SHA certificates and ensuring configuration files are kept in sync with the build pipeline, engineering teams can maintain secure, reliable SMS verification flows.

If your organization is scaling its mobile infrastructure and needs to hire react native developers for cross-platform apps with robust, enterprise-grade architecture, we can help streamline your delivery. contact us to explore how our dedicated remote engineering teams can elevate your technology stack.

Social Hashtags

#FirebaseAuthentication #FirebasePhoneAuth #FirebaseError17028 #SHA256 #AndroidDevelopment #ReactNative #GooglePlayIntegrity #GooglePlayAppSigning #FirebaseOTP #MobileAppDevelopment #AndroidDebugging #DevOps #CICD #FirebaseTroubleshooting #AppSecurity