Блог

Я могу запустить свое приложение Android AD B2C в эмуляторе, но когда я «создаю подписанный пакет», который создает AAB, и развертываю его для «внутреннего тестирования», затем загружаю его на устройство и запускаю, я получаю сбой (ниже). Это работало, и я развернул более ранние версии без нескольких URI для каждой среды, но копая глубже, я не понимаю, как это должно работать. Вот ошибка:

Создайте приложение multipleaccountpublicclient.Ошибка: URI перенаправления в файле конфигурации не совпадает с тем, который сгенерирован с именем пакета и хэшем подписи. Пожалуйста, проверьте uri в файле конфигурации и регистрацию вашего приложения на портале Azure.

Я не изменил хэш подписи, который я сгенерировал, следуя инструкциям на портале Azure:

Генерация хэша подписи разработки. Это будет меняться для каждой среды разработки.

В Mac OS,

 keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore | openssl sha1 -binary | openssl base64
 

Я вижу, что есть дополнительные инструкции для производства:

Генерация хэша рабочей подписи.

 keytool -exportcert -alias SIGNATURE_ALIAS -keystore PATH_TO_KEYSTORE | openssl sha1 -binary | openssl base64
 

Возможно, я неправильно понимаю это, но я не могу связать точки между инструкциями keytool для производства и «Расширенными режимами доставки Google Play», найденными в ссылке на справочный документ в блейке портала Azure для «Настройки вашего приложения для Android» в разделе «Генерация хэша вашей рабочей подписи»:

Для получения дополнительной помощи при подписании приложений ознакомьтесь с разделом Подписание вашего приложения для Android

Я понял из «Настройка вашего приложения для Android», что вам нужно несколько URI перенаправления, если вы используете один и тот же клиент B2C для нескольких сред (в данном случае dev и prod, поскольку оба указаны в блейде), и что для каждого требуется свой хэш подписи. Я заполняю пробелы здесь, поскольку я не смог найти это четко указано. Возможно, я просто пропустил это.

Команда «Хэш подписи разработки» содержит androiddebugkey и ~/.android/debug.хранилище ключей, где «хэш рабочей подписи» имеет SIGNATURE_ALIAS и PATH_TO_KEYSTORE, поэтому я полагаю, что сам хэш подписи действительно имеет значение. Я подумал, что, возможно, до тех пор, пока хэш был в конфигурации платформы B2C в качестве URI перенаправления Android, и он соответствовал хэшу в AndroidManifest.xml:

 <!--Intent filter to capture System Browser or Authenticator calling back to our app after sign-in-->
<activity
    android:name="com.microsoft.identity.client.BrowserTabActivity">
    <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:scheme="msauth"
            android:host="Enter_the_Package_Name"
            android:path="/Enter_the_Signature_Hash" />
    </intent-filter>
</activity>
 

…and in the configuration file (in my case the auth_config_multiple_account.json):

 {
  "client_id" : "e5737214-6372-472c-a85a-68e8fbe6cf3c",
  "redirect_uri" : "msauth://com.azuresamples.msalandroidapp/1wIqXSqBj7w+h11ZifsnqwgyKrY=",
  "account_mode" : "MULTIPLE",
  "broker_redirect_uri_registered": false,
  "authorities": [
    {
      "type": "B2C",
      "authority_url": "https://fabrikamb2c.b2clogin.com/tfp/fabrikamb2c.onmicrosoft.com/b2c_1_susi/",
      "default": true
    },
    {
      "type": "B2C",
      "authority_url": "https://fabrikamb2c.b2clogin.com/tfp/fabrikamb2c.onmicrosoft.com/b2c_1_edit_profile/"
    },
    {
      "type": "B2C",
      "authority_url": "https://fabrikamb2c.b2clogin.com/tfp/fabrikamb2c.onmicrosoft.com/b2c_1_reset/"
    }
  ]
}
 

Much like documented on GitHub as well. I have tried to resolve these questions by using the Redirect URI Issue FAQ and Redirect URI (reply URL) restrictions and limitations and Redirect URI for public client apps

My questions are:

1. Does the actual Signature Hash itself matter (i.e. can I use the same one for dev in prod)? So it does not simply need to be generated and match across the Azure portal, AndroidManifest.xml, and the raw json configuration file.
2. In a given B2C tenant supporting multiple environments do you need to have multiple redirect URIs with different signatures?
3. If you need to generate a production specific signature how do you do so using Google Play signing of an AAB?

I have a lot curiosity about the intent of B2C in regards to dev, test, prod environments (do you create multiple tenants to support multiple environments), but it is really a secondary question. Overall it would be good to have documentation on this inclusive of answers to my questions above.

UPDATE

Answer to question #1, it does seem to matter. I used a dev signature hash and one I had generated for the Google Play Store. Both are in in the Azure Portal as Redirect URIs. The Dev signature hash works when running from Android Studio and the google play signature hash does not work.