Давайте разберемся в технических вопросах: OAuth 2.0 для Office 11 для iOS 11

  1. Фон В недавнем сообщении мы рассмотрели, как обеспечить доступность новой функции электронной почты...
  2. iOS 11
  3. Запрос
  4. отклик
  5. iOS 10.3 Beta
  6. Запрос
  7. отклик
  8. Создание электронной почты OAuth 2.0: конечный пользователь
  9. Инициирование создания электронной почты OAuth 2.0 в iOS 11
  10. Автообнаружение
  11. Пример запроса
  12. команда
  13. отклик
  14. Почтовый ящик Office 365 (только в облаке) Ответ:
  15. Гибридное развертывание Office 365: локальный почтовый ящик
  16. Только локальная биржа
  17. отклик
  18. Аутентификация
  19. отклик
  20. Заголовок рефери
  21. Сломать Реферера
  22. IdP Redirect
  23. авторизация
  24. OAuth 2.0 в Azure
  25. Аккаунты iOS
  26. Учетные записи iOS за кулисами: конечный пользователь
  27. Учетные записи iOS за кулисами: администратор
  28. OAuth Token
  29. Обеспечение надежного доступа к совместимым устройствам
  30. Использование MobileIron Access для блокировки ненадежных устройств и приложений
  31. Отключить приложение учетных записей iOS в Azure
  32. Ограничить аутентификацию автообнаружения доверенными IP-адресами
  33. Ограничить автообнаружение, чтобы разрешить только трафик, отправляемый через MobileIron Standalone Sentry
  34. Последние мысли

Фон

В недавнем сообщении мы рассмотрели, как обеспечить доступность новой функции электронной почты OAuth 2.0 в iOS 11 и как предприятие может снизить риск несоответствия устройствам доступа к Office 365. Для тех, кто хочет получить больше обзора Вы можете найти это Вот , В этой статье мы подробно расскажем о том, как работает аутентификация электронной почты через OAuth 2.0, что происходит за кулисами, и о возможных шагах, которые предприятие может предпринять, чтобы снизить риск неуправляемых учетных записей электронной почты в дикой природе. Если технические детали этой функции вас не интересуют, перейдите к Вот чтобы просмотреть доступные варианты, чтобы ограничить эту функцию iOS 11.

Переход с iOS 10.3 Beta на iOS 11

Для тех, кто тестировал бета-версии iOS 10.3, пользовательский агент сменил бета-версию iOS 10.3 на недавно выпущенное обновление iOS 11. За несколько дней до выхода iOS 10.3 многие обнаружили, что ответ был заблокирован. В iOS 11 пользовательский агент теперь разрешен в публичной версии. В этом разделе мы рассмотрим различия между бета-версией iOS 10.3 и публичной версией iOS 11.

iOS 11

На начальном этапе автообнаружения почтовый клиент iOS звонит в Office 365 с помощью пользовательского агента Apple-iPhone9C1 / 1501.530400009. Мы можем смоделировать тот же вызов, который сначала делает устройство iOS при запуске автообнаружения с использованием CURL на нашем ПК.

Запрос

cURL -lv "https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/[EMAIL Address]? Protocol = ActiveSync" -A "Apple-iPhone9C1 / 1501.530400009"

отклик

При использовании нового агента пользователя почтовое приложение iOS получает следующий ответ от Office 365.
{
"Протокол": "ActiveSync",
"Веб-сайт": "https://outlook.office365.com/Microsoft-Server-ActiveSync"
}

iOS 10.3 Beta

На начальном этапе автообнаружения почтовый клиент ios звонит в Office 365 с помощью пользовательского агента Apple-iPhone9C1 / 1401.530400009.

Запрос

cURL -lv "https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/[EMAIL Address]? Protocol = ActiveSync" -A "Apple-iPhone9C1 / 1401.530400009"

отклик

{
«ErrorCode»: «NotSupportedClient»,
«ErrorMessage»: «Данный клиент ActiveSync не поддерживается»
}

Создание электронной почты OAuth 2.0: конечный пользователь

Как отмечалось в предыдущем посте, создание электронной почты OAuth 2.0 является управляемой пользователем функцией в iOS 11, и в настоящее время Apple не предоставила средства управления MDM для развертывания этого нового потока аутентификации в управляемых учетных записях электронной почты. Приведенное ниже видео демонстрирует взаимодействие с конечным пользователем при добавлении учетной записи Exchange Online.

Чтобы повторить то, что показывает видео:

  1. Пользователь выбирает почтовое приложение iOS
  2. Далее пользователь выбирает опцию Exchange
  3. Затем пользователь вводит свой адрес электронной почты и описание

Теперь давайте посмотрим, что будет дальше?

Инициирование создания электронной почты OAuth 2.0 в iOS 11

0 в iOS 11

После того, как пользователь выбирает следующее, ему предоставляется одноразовое всплывающее окно. Как видно из рисунка, пользователю предлагается «войти в свою учетную запись [[Домен]» с помощью Microsoft? », И ему предоставляется два варианта:« Настроить вручную »и« Войти ».

«Настроить вручную» следует традиционному пути создания учетной записи активного профиля.
«Вход» следует по пути автообнаружения, отправив запрос автообнаружения на outlook.office365.com.

Давайте посмотрим за кулисы на автообнаружение. Когда пользователь выбирает «Войти», устройство iOS сначала делает загадочный вызов на https://newaccountredirectdomain.apple.com . На момент написания неясно, что делает этот вызов.

Автообнаружение

Автообнаружение обращается к outlook.office365.com с адресом электронной почты пользователя. Запрос использует пример URL, показанный здесь:

Пример запроса

https://outlook.office365.com/autodiscover/autodiscover.json?Email=<email адрес> & Protocol = ActiveSync

Как показывает пример, автообнаружение использует протокол HTTPS. Мы можем смоделировать этот вызов с помощью CURL:

команда

curl -lv "https://outlook.office365.com/autodiscover/autodiscover.json?Email=<[email protected]>&Protocol=ActiveSync"

отклик

Ответ на первоначальный вызов автообнаружения зависит от того, где находится почтовый ящик. Мы протестировали следующие сценарии:

  1. Почтовый ящик Office 365 (только в облаке)
  2. Гибридное развертывание Office 365 с локальным почтовым ящиком
  3. Только локальная биржа

Почтовый ящик Office 365 (только в облаке) Ответ:

Если адрес электронной почты, встроенный в начальный вызов автообнаружения, найден в Office 365, outlook.office365.com отвечает следующим образом:

Протокол: "ActiveSync"
URL: "https://outlook.office365.com/Microsoft-Server-ActiveSync" Когда почтовый ящик обнаружен в Office 365, конечный пользователь начнет новый процесс проверки подлинности.

Гибридное развертывание Office 365: локальный почтовый ящик

На многих предприятиях Office 365 развертывается в гибридной конфигурации, в которой со временем выполняются миграции с локальных почтовых ящиков Exchange на Office 365. Ответы автообнаружения различаются в зависимости от того, как автообнаружение было настроено для домена. Многие предприятия указывают autodiscover.domain.com на внешние локальные службы клиентского доступа (CAS). Другие делают другие выборы. Для получения дополнительной информации о записях DNS, необходимых для Office 365, корпорация Майкрософт предоставляет отличную справочную страницу Вот , Более подробную информацию о процессе поиска автообнаружения можно найти в статье TechNet. Вот ,

Только локальная биржа

Помните, что независимо от архитектуры развертывания Exchange, когда пользователь выбирает «Вход» для настройки своей учетной записи Exchange, автообнаружение Office 365 всегда вызывает outlook.office365.com для обнаружения почтового ящика. Если почтовый ящик не найден в облачном почтовом ящике Office 365, ответ из Office 365 перенаправляет на соответствующий URL-адрес автообнаружения для домена, как показано в примере:

отклик

Первоначальный вызов Outlook.office365.com
GET /autodiscover/autodiscover.json?Email= < адрес электронной почты > & Protocol = ActiveSync HTTP / 1.1
Хост: outlook.office365.com
Перенаправление на местоположение автообнаружения предприятия
HTTP / 1.1 302 найдено
Расположение: https: // < имя автообнаружения > /autodiscover/autodiscover.json?Email= < адрес электронной почты > & Protocol = ActiveSync & RedirectCount = 1

Аутентификация

После того, как узел обмена получен через автообнаружение и обнаружен почтовый ящик Office 365, конечный пользователь перенаправляется к своему провайдеру идентификации (IdP). Идентифицированный вызов выполняется для https: // <хост обмена> / Microsoft-Server-ActiveSync с пустым заголовком авторизации. Пустой заголовок авторизации означает, что учетная запись электронной почты не была авторизована для доступа к электронной почте и должна пройти процедуру аутентификации. Мы можем смоделировать этот вызов с устройства на Office 365 через cURL.

cURL -lv "https://outlook.office365.com/Microsoft-Server-ActiveSync" -H "Авторизация: Носитель"

отклик

В ответе HTTP 401 Unauthorized конечная точка авторизации (authorization_uri) отвечает клиенту для запуска процесса аутентификации. Конечная точка Azure или универсальный идентификатор ресурса (URI) указывает на следующее:
https://login.windows.net/common/oauth2/authorize

Заголовок рефери

Когда пользователь перенаправляется из конечной точки Azure, реферер HTTP предоставляет информацию своему IdP для начала аутентификации и того, откуда был получен запрос. В приведенном ниже примере наш клиент Office 365 был объединен с SAML 2.0. Мы все еще изучаем, что можно найти, когда IdP объединен с Office 365 с WS-Federation:

https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&client_id=f8d98a96-0999-43f5-8af3-69971c7bb423&redirect_uri=com.apple.Preferences://oauth-redirect&scope=EAS.AccessAsUser.All&ui_locales=en- us&prompt=login&display=ios&[email protected]&resource=https: //outlook.office365.com

Сломать Реферера

URI авторизации: https://login.microsoftonline.com/common/oauth2/authorize
ClientID (уникальный идентификатор приложения в Azure): f8d98a96-0999-43f5-8af3-69971c7bb423
URI перенаправления: com.apple.Preferences: // oauth-redirect
Объем разрешений: EAS.AccessAsUser.All
Язык интерфейса: язык iOS-устройства
Login_hint: адрес электронной почты
Ресурс: https://outlook.office365.com

IdP Redirect

После того, как запрос на аутентификацию исходит в Office 365, служба отправляет ответ клиенту электронной почты для аутентификации с помощью своего Identity Provider (IdP). Почтовый клиент iOS использует контроллер представления Safari (SFVC) для перенаправления в Identity Provider и завершения процесса аутентификации.

авторизация

Как только конечный пользователь предоставит свои учетные данные и подтвердит подлинность в своем IdP, ему будет представлен экран подтверждения авторизации OAuth 2.0.

OAuth 2.0 в Azure

В этом блоге не рассказывается о том, как OAuth 2.0 реализован в Azure, но если вам интересно немного углубиться в это, вы можете найти следующую документацию по Azure. Вот , Существует также среда песочницы OAuth Вот это позволяет безопасную площадку для обучения.

Аккаунты iOS

После успешной аутентификации с помощью своего Identity Provider (IdP) конечному пользователю предоставляется грант на утверждение OAuth. Приложение, называемое «Учетные записи iOS», требует следующих разрешений для продолжения:

  1. Доступ к вашим почтовым ящикам
  2. Войдите в систему и прочитайте свой профиль

Доступ к вашим почтовым ящикам   Войдите в систему и прочитайте свой профиль

* Примечание. * Это разрешение на авторизацию OAuth 2.0 отображается только в первый раз, когда конечный пользователь пытается получить доступ к своей учетной записи электронной почты Office 365. Администратор также может автоматически принимать разрешения от имени своих корпоративных пользователей.

Учетные записи iOS за кулисами: конечный пользователь

Учетные записи iOS - это приложение, созданное Apple и зарегистрированное в Azure. Когда конечный пользователь примет приложение, он найдет приложение «Учетные записи iOS» на своем портале Office 365.

Чтобы снова протестировать грант авторизации учетных записей iOS для конечного пользователя, выберите Отменить на экране выше. При отзыве приложения конечному пользователю необходимо будет принять приложение учетных записей iOS при следующем добавлении своей учетной записи электронной почты Office 365.

Учетные записи iOS за кулисами: администратор

Когда конечный пользователь принимает разрешение на авторизацию электронной почты OAuth 2.0 для iOS 11, приложение «Учетные записи iOS» также создается за кулисами в клиенте Azure компании. Однако конечный пользователь должен пройти этот этап создания учетной записи, прежде чем приложение станет доступно в их клиенте Azure. На момент публикации сообщения учетные записи iOS недоступны для добавления в общедоступную галерею приложений Azure для настройки администратором. Мы обнаружили, что единственный способ добавить это приложение к арендатору компании - вручную выполнить создание учетной записи iOS 11 OAuth 2.0.

При первом успешном предоставлении конечным пользователем разрешения учетных записей iOS приложение будет добавлено в каталог приложений в Azure.

При первом успешном предоставлении конечным пользователем разрешения учетных записей iOS приложение будет добавлено в каталог приложений в Azure

Идентификатор приложения, также известный как clientID, является глобально уникальным приложением, созданным Apple в Azure. Этот идентификатор ( f8d98a96-0999-43f5-8af3-69971c7bb423 ) будет одинаковым для каждого клиента Azure.

OAuth Token

Azure использует стандарты на основе Токен JWT , Мы декодированный ниже для моего аккаунта выдан настоящий OAuth-токен. Мы обнаружили, что валидность токена - это разница между значением iat и exp . В нашем случае токен был действителен в течение часа и 5 минут.
{
"typ": "JWT",
"alg": "RS256",
"x5t": "9FXDpbfMFT2SvQuXh846YTwEIBw",
"kid": "9FXDpbfMFT2SvQuXh846YTwEIBw"
}
{
"aud": "https://outlook.office365.com",
"iss": "https://sts.windows.net/8392379d-8a98-4cb4-8cfe-5e7fa92e4e60/",
"iat": 1499289288,
"nbf": 1499289288,
"exp": 1499293188,
"acr": "1",
"aio": "ASQA2 / 8DAAAALGFisFdBqP3W1Nq + pKd1U5SmkCcn7nlGYonYDHfqXl8 =",
"amr": [
"PWD"
],
"appid": "f8d98a96-0999-43f5-8af3-69971c7bb423",
"appidacr": "0",
"enfpolids": [],
"фамилия": "[Фамилия]",
"данное_имя": "[Имя]",
"ipaddr": "[Внешний IP]",
"имя": "[ФИО]",
"oid": "f752c51d-7811-4453-8cf5-9637033cbd87",
"onprem_sid": "S-1-5-21-725690979-2191617849-2898786972-5273",
"platf": "2",
«puid»: «1003BFFD8D2D2594»,
"scp": "full_access_as_user",
"sub": "DL1ipWqUqwJycUehF6T1fKv0UMahVqXM5KkUwFWw41w",
"tid": "8392379d-8a98-4cb4-8cfe-5e7fa92e4e60",
"unique_name": "[Обычно электронная почта и / или UPN]",
"upn": "[UPN]",
"ver": "1.0"
}

Обеспечение надежного доступа к совместимым устройствам

Теперь, когда мы рассмотрели, как новое приложение iOS Account работает за кулисами, для корпоративных клиентов Office 365 наивысшим приоритетом является предотвращение несанкционированного доступа. В нашем предыдущем посте были определены текущие ограничения, но для незнакомых пользователей создание учетной записи электронной почты доступно только для управляемого и неуправляемого доступа к учетной записи. В результате наша текущая рекомендация - заблокировать эту возможность, чтобы обеспечить доступ к электронной почте Office 365 только зарегистрированным и совместимым устройствам. В этом разделе мы рассмотрим доступные варианты, чтобы заблокировать эту функцию от создания неуправляемой учетной записи электронной почты для Office 365.

Использование MobileIron Access для блокировки ненадежных устройств и приложений

Безопасность должна двигаться со скоростью мобильного телефона. MobileIron Access предоставляет мощные возможности условного доступа наряду с настраиваемой страницей исправления, которая снижает риск несоответствующих устройств доступа к Office 365. Мы рекомендуем клиентам использовать правила условного доступа, чтобы разрешить только управляемым учетным записям электронной почты, предоставленным MobileIron, доступ к их Exchange Online. Счета. С помощью настраиваемой страницы исправлений администраторы могут направлять пользователей на регистрацию своих устройств в MobileIron, чтобы они могли без проблем осуществлять аутентификацию в Office 365, включая Exchange Online, и обеспечить надлежащую защиту активов предприятия.

Для этого технически в MobileIron Access есть предварительно настроенные правила, которые могут применяться только к доверенным устройствам и приложениям, развернутым в качестве управляемых приложений их администратором EMM. Это позволяет только зарегистрированным и совместимым приложениям проходить проверку подлинности для своего поставщика удостоверений (IdP) и / или обеспечивать бесперебойную регистрацию. Когда незарегистрированное устройство перенаправляется в Access для проверки соответствия, на его настраиваемой странице соответствия пользователям будет предлагаться зарегистрировать свое устройство и / или использовать только утвержденные приложения. Чтобы поддержать это правило в Access:

  1. Примените доверенное приложение и устройство в качестве первого приоритета. Это правило включено по умолчанию.
  2. Добавьте правила ненадежных приложений iPhone и iPad. Эти правила будут блокировать запросы аутентификации, исходящие от несовместимых приложений и устройств на платформе iOS.

Эти правила будут блокировать запросы аутентификации, исходящие от несовместимых приложений и устройств на платформе iOS

В качестве альтернативы для предприятий, имеющих федеративный доступ к Office 365 с SAML 2.0, предопределенное правило в Access, называемое OAuth собственной электронной почты iOS , явно блокирует любые запросы OAuth 2.0 для собственной электронной почты iOS. Сегодня предопределенное правило OAuth Native Email для iOS в настоящее время недоступно для тех предприятий, которые настроили Access с WS-Federation.

Отключить приложение учетных записей iOS в Azure

Приложение учетных записей iOS, созданное в рамках описанного выше рабочего процесса, также можно отключить в каталоге приложений Azure. Для тех предприятий, которые не развернули MobileIron Access, клиенту электронной почты будет разрешено проходить аутентификацию на своем провайдере идентификации (IdP), но разрешение на авторизацию вызовет ошибку. Отключение учетных записей iOS не так элегантно, как страница исправлений MobileIron Access, на которой пользователю предлагается зарегистрировать свое устройство. Отключение приложения заблокирует использование приложения в клиенте. В настоящее время нам не удалось успешно настроить условный доступ Azure, чтобы получить более детализированные элементы управления.
Для этого:

  1. Войдите на портал Azure ( https://portal.azure.com ) с учетными данными администратора.
  2. Выберите значок Azure Active Directory в левом окне навигации.
  3. Выберите корпоративные приложения
  4. Выбрать все приложения
  5. Выберите учетные записи iOS. * Обратите внимание, что это будет доступно только после того, как конечный пользователь выполнит описанный выше процесс создания учетной записи на iOS 11. Его нельзя публично добавить в каталог приложений Azure.
  6. В приложении «Аккаунты iOS» выберите « Свойства».
  7. На вкладке Свойства измените Включено для пользователей, чтобы войти с ДА на НЕТ.
  8. Выберите Сохранить. Для получения дополнительной информации об отключении входа пользователя, пожалуйста, посетите страницу Microsoft Azure AD. Вот ,

Кроме того, администраторы могут установить политику, если конечным пользователям разрешено регистрировать приложения для клиента своей компании Azure. По умолчанию конечным пользователям разрешено регистрировать приложения в Azure Tenants. На портале Azure администраторы могут устанавливать пользовательские настройки для всего арендатора, чтобы конечные пользователи не могли регистрировать приложения, такие как учетные записи iOS, в Azure. Для получения дополнительной информации вы можете найти документы Microsoft, расположенные Вот ,

Для предприятий, которые также используют MobileIron Access, отключение учетных записей iOS в их клиенте Azure является дополнительным.

Ограничить аутентификацию автообнаружения доверенными IP-адресами

Для тех, кто не может получить достаточное количество заявлений о приключениях с помощью своего Identity Provider (IdP), мы обнаружили, что определенные типы заявок могут использоваться для ограничения доступа к доверенным устройствам. В прошлом тип заявления X-MS-Client-Application мог использоваться для ограничения Microsoft.Exchange.Activesync. В iOS 10.3 и более ранних версиях многие наши клиенты внедрили правило AD FS, аналогичное приведенному ниже, которое ограничивает Activesync только автономными часами.

существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
&& НЕ существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value = ~ "\ b204 \ .8 \ .168 \ 0,222 \ Ь | \ B198 \ 0,61 \ 0,61 \ 0,63 \ Ь | \ B198 \ .61 \ 0,61 \ 0,72 \ Ь | \ b144 \ 0,86 \ 0,246 \ 0,246 \ Ь | \ b50 \ 0,185 \ 0,54 \ 0,152 \ Ъ "])
=> проблема (Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

С появлением iOS 11 и его возможности электронной почты OAuth 2.0 мы обнаружили, что вышеприведенное правило больше не блокирует трафик Activesync, потому что тип заявления приложения имеет отношение только к клиентам, исходящим из активного профиля. Чтобы ограничить эту новую функцию, нам нужно было ограничить автообнаружение только доверенными IP-адресами. Ограничение автообнаружения может повлиять на все корпоративные устройства, имеющие доступ к электронной почте; не только устройства, проходящие аутентификацию через ActiveSync. Мы настоятельно рекомендуем использовать другие варианты выше, прежде чем пытаться ограничить автообнаружение с помощью утверждений. Поскольку автообнаружение широко используется для каждого почтового клиента, предприятие должно учитывать все IP-адреса, которые будут пытаться получить доступ к электронной почте с помощью Office 365. Для многих предприятий они должны учитывать свою корпоративную сеть, устаревшие устройства и решения VPN. которые не управляются MobileIron, а Standalone Sentries для MobileIron регистрирует устройства, аутентифицируемые с помощью ActiveSync. Если приведенное выше предупреждение не отговаривает вас от попытки, ниже приведен пример правила, которое было успешно протестировано.

Ограничить автообнаружение, чтобы разрешить только трафик, отправляемый через MobileIron Standalone Sentry

существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.Autodiscover"])
&& НЕ существует ([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value = ~ "\ b204 \ .8 \ .168 \ 0,222 \ Ь | \ B198 \ 0,61 \ 0,61 \ 0,63 \ Ь | \ B198 \ .61 \ 0,61 \ 0,72 \ Ь | \ b144 \ 0,86 \ 0,246 \ 0,246 \ Ь | \ b50 \ 0,185 \ 0,54 \ 0,152 \ Ъ "])
=> проблема (Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

Последние мысли

В этой статье мы проанализировали новый поток электронной почты iOS 11 OAuth 2.0 для Office 365, который включал создание приложения учетных записей iOS в Azure. Поскольку предприятия используют iOS 11 и Office 365, администраторы должны обеспечить доступ к электронной почте с совместимых устройств. Наш рекомендуемый подход может быть определен в два этапа. Первым шагом является использование MobileIron Access с настраиваемой страницей соответствия, чтобы конечные пользователи могли легко обеспечить совместимость своих устройств. Во-вторых, администратор клиента Azure должен отключить приложение учетных записей iOS в Azure. Это гарантирует, что конечные пользователи имеют управляемую и беспроблемную работу с Office 365 для собственной электронной почты iOS при одновременной защите от несоответствующих учетных записей электронной почты. Хотя описанные выше варианты были протестированы с этой функцией iOS 11, этот список не является исчерпывающим, и могут быть другие варианты, которые можно рассмотреть. Для всех наших замечательных клиентов и партнеров я с нетерпением ожидаю услышать о вашем собственном опыте тестирования в нашем сообществе. Вот ,

EMAIL Address]?
EMAIL Address]?
Как видно из рисунка, пользователю предлагается «войти в свою учетную запись [[Домен]» с помощью Microsoft?
Json?
Json?
Json?
Json?
Com/common/oauth2/authorize?