Судя по вашему коду, вы используете Аутентификация, управляемая клиентом, с мобильными приложениями Azure. Для проверки подлинности/авторизации службы приложений, например мобильного клиента, клиенту будет выдан веб-токен JSON (JWT), который будет представлен в заголовке x-zumo-auth при отправке запроса на мобильный сервер. Дополнительные сведения см. в разделе Как работает аутентификация в Службе приложений. Вот токен JWT при использовании диспетчера трафика Azure с мобильным приложением. Мы могли бы использовать jwt.io для декодирования токена:
Для токена JWT он будет использовать переменную среды WEBSITE_AUTH_SIGNING_KEY для подписи audience, issuer, Claims. Дополнительные сведения см. в разделе здесь о том, как использовать пользовательскую аутентификацию для вашего приложения.
Каждое мобильное приложение имеет разные WEBSITE_AUTH_SIGNING_KEY, вы можете использовать куду и нажмите Окружающая среда, чтобы найти его. Более того, я попытался обновить два моих мобильных приложения, чтобы они использовали один и тот же ключ подписи, но не получил разрешения.
Ваш LoginAsync отправит следующий запрос:
POST https://<yourname>.trafficmanager.net/.auth/login/facebook
Body {"access_token":"<access_token_from_facebook>"}
Вы можете использовать fiddler для захвата сетевой трассировки.
Можно ли использовать диспетчер трафика Azure с мобильными приложениями, особенно с входом через социальные сети?
Для пользовательской аутентификации вы можете настроить ключ подписи в файле web.config. Для входа через социальные сети и использования проверки подлинности, предоставляемой azure, вы не могли совместно использовать ключ подписи между различными мобильными приложениями. Кроме того, если вы установите Routing method на Geographic и ваши мобильные приложения находятся в разных географических точках, я предполагаю, что ваш сценарий может работать должным образом.
ОБНОВЛЕНИЕ 1:
После некоторых испытаний я обнаружил, что вы можете указать параметр WEBSITE_AUTH_SIGNING_KEY в колонке «НАСТРОЙКИ > Настройки приложения» вашего мобильного приложения, чтобы переопределить переменную среды WEBSITE_AUTH_SIGNING_KEY следующим образом:
Примечание. Ключ подписи должен представлять собой хешированную строку SHA-256. Вы можете синхронизировать ключ между двумя мобильными приложениями или создать собственный ключ. После настройки параметра вы можете использовать kudu для проверки новейших файлов WEBSITE_AUTH_SIGNING_KEY.
ОБНОВЛЕНИЕ 2:
моя проблема заключается в том, чтобы выяснить, как использовать социальную аутентификацию с двумя разными мобильными приложениями, где перенаправление диспетчером трафика происходит на основе производительности
В официальной документации упоминается о метод маршрутизации трафика Performance следующим образом:
Производительность. Выберите «Производительность», если у вас есть конечные точки в разных географических точках и вы хотите, чтобы конечные пользователи использовали «ближайшую» конечную точку с наименьшей сетевой задержкой.
Я провел тест, вы можете сослаться на него. Вот конечные точки в моем профиле диспетчера трафика:
Примечание. Мои два мобильных приложения настроили одно и то же Client Id для аутентификации MSA и установили одно и то же значение WEBSITE_AUTH_SIGNING_KEY в разделе "НАСТРОЙКИ > Настройки приложения" для кодирования/декодирования токена.
Для моей конечной точки API /api/values я просто возвращаю переменную среды WEBSITE_HOSTNAME следующим образом:
return Request.CreateResponse(new { WEBSITE_HOSTNAME =Environment.GetEnvironmentVariable("WEBSITE_HOSTNAME") });
Для метода маршрутизации Performance все мои запросы будут направляться на bruce-mobile02.azurewebsites.net:
Для метода маршрутизации Weighted я настроил один и тот же ВЕС для двух моих конечных точек. В моем тесте запросы с тем же AuthenticationToken, что и значение заголовка x-zumo-auth для авторизации, будут направляться на мои две конечные точки следующим образом:
person
Bruce Chen
schedule
13.10.2017
