The SDK should fetch the 'redirect_uri' programatically instead of fetching it from the MSAL configuration file

[umangmathur92]

An Android APK can have 3 unique signatures/signing-key:

1. Debug (debug build variant)
2. Release (release build variant)
3. Play App Signing (Google Play re-signs the release APK after it is uploaded to Play Console)

The MSAL config file contains the redirect_uri. The redirect_uri consists of the BASE64_URL_ENCODED_PACKAGE_SIGNATURE. The SDK needs this config file to function properly. Since there are 3 possible unique package signatures - this mandates 3 unique config files with different redirect_uri.

Right now, I am able to switch between MSAL config files depending on whether it is a debug build or a release build. i.e., I am able to switch between 2 different MSAL config files (gradle allows me to specify certain attributes based on the build type - release or debug). However, there are 3 unique keys that may be used to sign the APK and gradle allows us to specify just 2 build types.

redirect_uri structure: msauth://<YOUR_PACKAGE_NAME>/<YOUR_BASE64_URL_ENCODED_PACKAGE_SIGNATURE>

Inside the app-level build.gradle file:

buildTypes {
        debug {
            manifestPlaceholders = [keystoreHash: 'abcdefghijkl='] //debug APK package signature
        }
        release {
            manifestPlaceholders = [keystoreHash: 'pqrstuvwxyno='] // Either one of Release APK or Play-Store APK package signature. This is problematic
        }
    }

Inside AndroidManifest.xml:

<activity
    android:name="com.microsoft.identity.client.BrowserTabActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:host="com.my.package.name"
            android:path="/${keystoreHash}"
            android:scheme="msauth" />
    </intent-filter>
</activity>

What this implies is that at any given point of time, at least one of the 3 APKs don't allow me to sign in using Microsoft. I do not face the same issue while using a google Sign in SDK or Facebook login SDK because those SDKs programmatically fetch the package-signature(keystore hash).

My use-case:

• debug builds are used for development and automated tests, debug through code, generate code coverage stats.
• Release APK is distributed to certain customers directly
• Google Play Resigned APK is what gets distributed through the Play Store

As of today I am unable to distribute 'Release APK' to customers directly because gradle allows me to choose between just 2 possible configurations even though there are 3 uniquely signed APKs.

Preferred Solution
The SDK should fetch the 'redirect_uri' programatically instead of fetching it from the MSAL configuration file. No other popular authentication SDK forces developers to manually specify the package signature.
The verifyRedirectUriWithAppSignature() method inside com.microsoft.identity.client.PublicClientApplicationConfiguration.java already contains similar code albeit used for verification purposes.

Alternative Solution2
Would the following approach to modifying the IntentFilter for the BrowserTabActivity work ?
Inside AndroidManifest.xml:

<activity
    android:name="com.microsoft.identity.client.BrowserTabActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:host="com.my.package.name"
            android:path="/${keystoreHash1}"
            android:scheme="msauth" />
        <data
            android:host="com.my.package.name"
            android:path="/${keystoreHash2}"
            android:scheme="msauth" />
    </intent-filter>
</activity>

Alternative SDKs
Google, Facebook login SDKs work flawlessly and there is no such limitation when I use those SDKs. The paradigm being used in the MSAL-Android SDK is sub-optimal in my opinion.

[umangmathur92]

Issues reported by other developers related to this:
#1304
#1920
#1550
#1543
#1531

[negoe]

@umangmathur92 Really appreciate the detail investigation and suggestion. We plan to address this issue to make experience with sample better. I would also like to connect with you to learn more about your experience with MSAL if you have further feedback. Please email me at [email protected] and I will schedule a call for us.

[umangmathur92]

@negoe Yes. I'd like to get on a call to discuss this further.
Will send you an email within the next few days to schedule it 👍

[leandrobravo]

@negoe do you have more information about the issue? I'm facing some issue only when the app downloaded from google play store.

[negoe]

@umangmathur92 Just checking if you sent an email, hope it did not land in my junk folder.
@leandrobravo What kind of information are you looking for regarding this?