{"id":8749,"date":"2022-06-11T00:10:04","date_gmt":"2022-06-11T00:10:04","guid":{"rendered":"https:\/\/blogs.aaddevsup.xyz\/?p=8749"},"modified":"2022-06-16T15:41:49","modified_gmt":"2022-06-16T15:41:49","slug":"how-to-solve-failed-authentication-after-publishing-app-to-google-play-store","status":"publish","type":"post","link":"https:\/\/blogs.aaddevsup.xyz\/2022\/06\/how-to-solve-failed-authentication-after-publishing-app-to-google-play-store\/","title":{"rendered":"How to Solve Failed Authentication After Publishing App to Google Play Store"},"content":{"rendered":"\n

Issue Description<\/h2>\n\n\n\n

You successfully implemented Azure AD Authentication in your Android app with the Microsoft Authentication Library. The application built and executed perfectly and passed all QA testing with flying colors. And then you published the application on Google Play. And authentication doesn’t work after installing the app. <\/p>\n\n\n\n

If you exposed authentication error messages to the user, or had them sent to your team, then you might see an error like this:<\/p>\n\n\n\n

“The redirect URI in the configuration file doesn’t match with the one generated with the package name and signature hash. Please verify the uri in the config file and your app registration in Azure portal.”<\/mark><\/p>\n\n\n\n

Another potential behavior that might indicate this problem is this: During development and QA testing, you successfully set up your app to use a supported broker to handle authentication and SSO. However, after deployment through Google Play and installation, the app no longer uses the broker for authentication.<\/p>\n\n\n\n

The Cause<\/h2>\n\n\n\n

When an Android application is built for installation on a device, it is built as an “apk” compressed package and then signed by a certificate. This certificate signing ensures that the person who built the application was the one who owns the private signing key. This prevents potential impersonation attempts where a hacker might modify the application in a harmful way since the hacker will not be able to sign their version of the application with the original private signing key.<\/p>\n\n\n\n

In the past, Android developers owned and maintained their own private signing keys. However, now, Google Play Services generate and maintain their own private signing key for an Android Developer. This is actually a good thing, since the key will be securely stored by Google. The developer still maintains an upload key so that Google Play Services can verify the authenticity of an uploaded app bundle, but the actual signing is done by the Google-owned signing certificate when a user installs the app on their device.<\/p>\n\n\n\n

How is this relevant? The Microsoft Authentication Library (MSAL) for Android Native and Microsoft Supported Authentication Brokers use the public signature hash of an installed application to identify it during interaction through the Android Operating system necessary during authentication. The public signature hash of an application installed by Google Play will be different from the same application installed before publishing to Google Play. Because of this, Msal will be configured to use the incorrect signature hash.<\/p>\n\n\n\n

How To Fix It<\/h2>\n\n\n\n

Generally, there are three major steps in solving this issue. <\/p>\n\n\n\n