Новые возможности для проверки подлинности.

Корпорация Майкрософт периодически добавляет и изменяет возможности и функции платформы удостоверений Майкрософт в целях повышения безопасности, удобства использования и соответствия стандартам.

Если не указано иное, описанные здесь изменения применяются только к приложениям, зарегистрированным после указанной даты изменения.

Регулярно проверяйте эту статью, чтобы узнать следующее:

• Известные проблемы и часто задаваемые вопросы
• Изменения протокола
• Нерекомендуемые функции.

Совет

Чтобы получать уведомления об обновлениях на этой странице, укажите данный URL-адрес в инструменте чтения RSS-канала:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Август 2024 г.

Федеративные учетные данные удостоверения теперь используют сопоставление с учетом регистра

Дата действия: сентябрь 2024 г.

Влияние протокола: федерация удостоверений рабочей нагрузки

Изменение

Ранее при сопоставлении федеративных учетных данных удостоверений (FIC) issuersubjectи audience значений соответствующих issuerзначений audience subject, содержащихся в маркере, отправляемом в идентификатор Microsoft Entra по внешнему поставщику удостоверений, использовался сопоставление без учета регистра. Чтобы обеспечить более точное управление клиентами, мы переключимся на применение сопоставления с учетом регистра.

Недопустимый пример:

• Тема токена: repo:contoso/contoso-org:ref:refs/heads/main
• Тема FIC: repo:Contoso/Contoso-Org:ref:refs/heads/main

Эти два значения субъекта не соответствуют регистру, поэтому проверка завершается ошибкой. К и audience проверке применяется issuer тот же механизм.

Это изменение будет применено изначально к приложениям или управляемым удостоверениям, созданным после August 14th, 2024. Неактивные приложения или управляемые удостоверения, определяемые отсутствием запросов федерации удостоверений рабочей нагрузки, сделанных указанным приложением или управляемым удостоверением между периодом August 1st, 2024 August 31st, 2024, требуются для использования September 27th, 2024сопоставления с учетом регистра. Для активных приложений сопоставление без учета регистра происходит позже.

Чтобы лучше выделить ошибки из-за нечувствительности регистра, мы перенаправляем сообщение об ошибке для AADSTS700213. Теперь это состояние;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

Заполнитель '{subject}' предоставляет значение утверждения субъекта, содержащегося в маркере, отправляемом из внешнего поставщика удостоверений в идентификатор Microsoft Entra ID. Этот шаблон ошибки также используется для сбоев без учета регистра, окружающих issuer и audience проверки. Если возникла эта ошибка, необходимо найти учетные данные федеративного удостоверения, соответствующие issuersubjectошибке или audience указанные в ошибке, и убедиться, что соответствующие значения эквивалентны с учетом регистра. Если имеется несоответствие, необходимо заменить текущее issuersubjectзначение или audience значение в FIC subjectissuerзначением или audience значением, содержащимся в сообщении об ошибке.

Примечание.

Для клиентов службы приложение Azure, использующих GitHub Actions и выполнив эту ошибку, можно перейти к файлу /.github/workflows рабочего процесса в репозитории GitHub и обновить свойство среды name до "Production" "production". Это руководство применимо только для сценариев службы приложение Azure. Если вы столкнулись с этой ошибкой в другом сценарии, обратитесь к приведенным выше рекомендациям.

Июнь 2024 г.

Приложения должны быть зарегистрированы в каталоге

Дата действия: июнь 2024 г.

Затронутые конечные точки: версии 1.0 и 2.0

Затронутый протокол: все потоки

Изменение

Ранее при регистрации приложения с помощью регистрации приложений Microsoft Entra, если пользователь выполнил вход с помощью личной учетной записи Майкрософт (MSA), он мог бы связать приложение только с их личная учетная запись. Это означает, что приложение не будет связано с или содержится в любом каталоге (также называемом "клиентом" или "организацией"). Однако начиная с июня 2024 года все приложения должны быть зарегистрированы в каталоге. Это может быть существующий каталог или новый, создаваемый пользователем личной учетной записи Майкрософт для размещения приложений Microsoft Entra и других ресурсов Майкрософт. Пользователи могут легко создать новый каталог для использования для этой цели, присоединившись к программе разработчика Microsoft 365 или зарегистрироваться в Azure.

Регистрация приложения в каталоге, а не только связывание его с личная учетная запись, имеет различные преимущества. Например:

• Приложения, зарегистрированные в каталоге, имеют больше возможностей, таких как возможность добавления нескольких владельцев в приложение и возможность издателя проверить приложение.
• Приложение находится в том же месте, что и другие ресурсы Майкрософт, которые разработчик использует, например ресурсы Azure.
• Приложение получает улучшенные преимущества устойчивости.

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

Октябрь 2023

Обновлен запрос пользовательского интерфейса RemoteConnect

Дата действия: октябрь 2023 г.

Затронутые конечные точки: версии 1.0 и 2.0

Влияние протокола: RemoteConnect

RemoteConnect — это поток между устройствами, используемый для брокера проверки подлинности Майкрософт и связанных сценариев Microsoft Intune с использованием первичных маркеров обновления. Чтобы предотвратить фишинговые атаки, поток RemoteConnect получает обновленный язык пользовательского интерфейса, чтобы вызвать, что удаленное устройство (устройство, инициирующее поток) сможет получить доступ к любым приложениям, используемым вашей организацией после успешного завершения потока.

Появится запрос, который будет выглядеть примерно так:

Июнь 2023 г.

Упущение утверждений электронной почты с непроверенным владельцем домена

Дата действия: июнь 2023 г.

Затронутые конечные точки: версии 1.0 и 2.0

Изменение

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

Сообщение электронной почты считается владельцем домена, проверяемое, если:

1. Домен принадлежит клиенту, где находится учетная запись пользователя, и администратор клиента выполнил проверку домена.
2. Сообщение электронной почты из учетной записи Майкрософт (MSA).
3. Сообщение электронной почты из учетной записи Google.
4. Электронная почта использовалась для проверки подлинности с помощью потока одноразового секретного кода (OTP).

Также следует отметить, что учетные записи Facebook и SAML/WS-Fed не имеют проверенных доменов.

Май 2023 г.

Роль администратора Power BI будет переименована в администратора Fabric.

Дата действия: июнь 2023 г.

Затронутые конечные точки:

• Перечисление roleDefinitions — Microsoft Graph версии 1.0
• Список directoryRoles — Microsoft Graph версии 1.0

Изменение

Роль администратора Power BI переименована в администратора Fabric.

23 мая 2023 г. Корпорация Майкрософт представила Microsoft Fabric, которая обеспечивает интеграцию данных на основе фабрики данных, инженерию данных Synapse, хранилище данных, обработку и анализ данных в режиме реального времени и бизнес-аналитику (BI) с Power BI — все размещено в решении SaaS, ориентированном на озеро. Администрирование клиента и емкости для этих возможностей централизованно выполняется на портале администрирования Fabric (ранее называемом порталом администрирования Power BI).

Начиная с июня 2023 года роль администратора Power BI переименовывается в администратора Fabric, чтобы соответствовать изменяющейся области и ответственности за эту роль. Все приложения, включая идентификатор Microsoft Entra, API Microsoft Graph, Microsoft 365 и GDAP, начнут отражать новое имя роли в течение нескольких недель.

Как напоминание, код приложения и скрипты не должны принимать решения на основе имени роли или отображаемого имени.

Декабрь 2021 г.

Пользователи AD FS увидят дополнительные запросы на вход, которые позволяют убедиться в том, что в систему входит надлежащий пользователь.

Дата вступления в силу: декабрь 2021 г.

Затронутые конечные точки: встроенная проверка подлинности Windows

Затронутый протокол: встроенная проверка подлинности Windows

Изменение

Сейчас, когда пользователь направляется в AD FS для проверки подлинности, он автоматически входит в любую учетную запись, у которой уже есть сеанс с AD FS. Этот автоматический вход в систему происходит даже в том случае, если пользователь собирался войти в другую учетную запись. Чтобы уменьшить частоту этого неправильного входа, начиная с декабря идентификатор Microsoft Entra отправит prompt=login параметр в AD FS, если диспетчер веб-учетных записей в Windows предоставляет идентификатор Microsoft Entra ID login_hint во время входа, что указывает, что для входа требуется конкретный пользователь.

Если выполнены указанные выше требования (WAM используется для отправки пользователю идентификатора Microsoft Entra для входа, login_hint включен и экземпляр AD FS для домена пользователя поддерживает prompt=login) пользователь не будет автоматически входить и вместо этого попросил предоставить имя пользователя для продолжения входа в AD FS. Если пользователь хочет выполнить вход в существующий сеанс AD FS, он может выбрать параметр "Продолжить как текущий пользователь", отображаемый под запросом на вход. В противном случае он может указать имя пользователя, которое хочет использовать для входа.

Это изменение будет развертываться в декабре 2021 г. в течение нескольких недель. При этом поведение входа не изменится для:

• приложений, напрямую использующих IWA;
• приложений, использующих OAuth;
• доменов, которые не являются федеративными для экземпляра AD FS

2021 октября

Ошибка 50105 исправлена, чтобы не допускать возвращения interaction_required во время интерактивной проверки подлинности

Дата вступления в силу: октябрь 2021 г.

Затронутые конечные точки: версии 1.0 и 2.0

Затронутый протокол: все потоки пользователей для приложений, которым необходимо назначение пользователей

Изменение

Ошибка 50105 (текущее обозначение) выдается, когда пользователь без назначения пытается войти в приложение, для которого администратор разрешил вход только назначенным пользователям. Это общий шаблон управления доступом, и часто пользователи вынуждены искать администратора, чтобы запросить назначение для разблокировки доступа. Ошибка приводила к тому, что выполнялись бесконечные циклы в закодированных приложениях, которые правильно обрабатывали ответ об ошибке interaction_required. interaction_required сообщает приложению выполнять интерактивную проверку подлинности, но даже после этого идентификатор Microsoft Entra ID по-прежнему возвращает ответ на ошибку interaction_required .

Сценарий ошибки обновлен, поэтому во время неинтерактивной проверки подлинности (где prompt=none используется для скрытия пользовательского интерфейса) приложению будет дано указание выполнить интерактивную проверку подлинности с помощью ответа об ошибке interaction_required. В последующей интерактивной проверке подлинности идентификатор Microsoft Entra теперь будет содержать пользователя и отображать сообщение об ошибке напрямую, предотвращая возникновение цикла.

Следует помнить, что код приложения не должен принимать решения на основе строк кода ошибки, например AADSTS50105. Вместо этого следуйте нашим рекомендациям по обработке ошибок и используйте стандартизированные ответы проверки подлинности, например, interaction_required и login_required, найденные в стандартном error поле ответа. Другие поля ответа предназначены только для использования специалистами, занимающимися устранением соответствующих проблем.

Вы можете просмотреть текущий текст ошибки 50105 и многое другое в службе поиска ошибок: https://login.microsoftonline.com/error?code=50105.

Для URI AppId в приложениях с одним клиентом потребуется использовать схему по умолчанию или проверенные домены.

Дата вступления в силу: октябрь 2021 г.

Затронутые конечные точки: версии 1.0 и 2.0

Затронутый протокол: все потоки

Изменение

Для приложений с одним клиентом добавление или обновление URI AppId проверяет, указан ли домен в URI схемы HTTPS в проверенном списке доменов в клиенте клиента или что значение использует схему по умолчанию (api://{appId}), предоставленную идентификатором Microsoft Entra. Это может помешать приложению добавить URI AppId, если домен не входит в список проверенных доменов или значение не использует схему по умолчанию. Дополнительные сведения о проверенных доменах см. в документации по личным доменам.

Изменение не влияет на существующие приложения, использующие непроверенные домены в их URI AppID. Проверка выполняется только для новых приложений, а также если существующее приложение обновляет URI идентификатора или добавляет новый в коллекцию identifierUri. Новые ограничения применяются только к URI, добавленным в коллекцию identifierUris приложения после 15 октября 2021 г. URI AppId, уже находящиеся в коллекции identifierUris приложения на момент вступления ограничения в силу 15 октября 2021 г., будут продолжать использоваться, даже если вы добавите новые URI в эту коллекцию.

Если запрос не проходит проверку, API приложения для создания или обновления вернет клиенту 400 badrequest с указанием HostNameNotOnVerifiedDomain.

Поддерживаются следующие форматы URI идентификатора приложения на основе схемы HTTP и API. Замените значения заполнителей, как описано в списке, что находится под таблицей.

Поддерживаемый идентификатор приложения Форматы URI	Пример: URI идентификатора приложения
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<строка>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId> — свойство идентификатора приложения (appId) объекта приложения.
• <string> — строковое значение для узла или сегмента пути к API.
• <tenantId> — идентификатор GUID, созданный Azure для представления клиента в Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, где <tenantInitialDomain> — это исходное доменное имя, которое создатель клиента задает при создании клиента.
• <verifiedCustomDomain> — проверенный личный домен , настроенный для клиента Microsoft Entra.

Примечание.

Если вы используете схему api://, строковое значение нужно добавить непосредственно после "api://". Пример: api://<строка>. Это строковое значение может быть идентификатором GUID или произвольной строкой. Если добавить значение идентификатора GUID, оно должно совпадать с идентификатором приложения или идентификатором арендатора. Значение URI идентификатора приложения должно быть уникальным для вашего арендатора. Если вы добавите api://<tenantId> в качестве URI идентификатора приложения, никто другой не сможет использовать этот URI в другом приложении. Мы рекомендуем вместо этого использовать api://<appId> или схему HTTP.

Внимание

Значение URI идентификатора приложения не должно заканчиваться символом косой черты "/".

Примечание.

Несмотря на то, что это безопасно для удаления идентификаторов Uris, для регистрации приложений в текущем клиенте, удаление идентификатора Uris может привести к сбою клиентов для других регистраций приложений.

Август 2021 г.

Условный доступ будет активироваться только для явно запрошенных областей

Срок вступления в силу: август 2021 г. с постепенным развертыванием начиная с апреля.

Затронутые конечные точки: версии 2.0.

Затронутый протокол: все потоки, использующие динамическое согласие

На сегодняшний день приложения, использующие динамическое согласие, получают все разрешения, на которые они дали согласие, даже если они не были запрошены в параметре scope по имени. Приложение, запрашивающее только user.read, но с согласием files.read, может быть вынуждено, например, передать требование условного доступа, назначенное для files.read.

Чтобы уменьшить количество ненужных запросов условного доступа, идентификатор Microsoft Entra изменяет способ предоставления областей приложениям, поэтому только явным образом запрашиваемые области запускают условный доступ. Приложения, зависящие от предыдущего поведения идентификатора Microsoft Entra, включают все области в токене,независимо от того, запрашиваются ли они или не могут прерваться из-за отсутствующих областей.

Впредь приложения будут получать маркеры доступа с набором разрешений, которые запрошены в данном запросе и которые имеют согласие, не требующее запроса условного доступа. Области маркера доступа отражаются в параметре scope ответа маркера.

Это изменение будет внесено для всех приложений, за исключением тех, для которых наблюдается зависимость от этого поведения. Разработчики получат информацию, если они исключены из этого изменения, так как они могут иметь зависимость от дополнительных запросов условного доступа.

Примеры

Приложение имеет согласие на user.read, files.readwrite и tasks.read. К files.readwrite применимы политики условного доступа, к двум другим — нет. Если приложение выполняет запрос маркера для scope=user.read, а текущий пользователь, выполнивший вход в систему, не предоставил никакие политики условного доступа, маркер будет иметь разрешения user.read и tasks.read. tasks.read включается, поскольку приложение имеет соответствующее согласие, и для него не требуется применение политики условного доступа.

Если затем приложение запрашивает scope=files.readwrite, будет активирован условный доступ, требуемый клиенту, что заставит приложение отображать интерактивный запрос проверки подлинности, в котором может быть удовлетворена политика условного доступа. Возвращенный маркер будет содержать все три области.

Если приложение выполняет один последний запрос для любой из трех областей (например, scope=tasks.read), идентификатор Microsoft Entra увидит, что пользователь уже выполнил политики условного доступа, необходимые для files.readwriteэтого, и снова выдает маркер со всеми тремя разрешениями в нем.

Июнь 2021 года

Теперь в интерфейсе потока кода устройства отображается запрос на подтверждение приложения

Дата вступления в силу: июнь 2021 г.

Затронутые конечные точки: версии 1.0 и 2.0

Затронутый протокол: поток кода устройства

Чтобы предотвратить фишинговые атаки, поток кода устройства теперь содержит подсказку, которая проверяет, входит ли пользователь в приложение, которое ожидается.

Отображаемый запрос выглядит следующим образом:

Май 2020 г.

Исправление ошибки. Идентификатор Microsoft Entra больше не закодирует параметр состояния дважды

Срок вступления в силу: май 2021 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: все потоки, которые заходят в конечную точку /authorize (неявный поток и поток кода авторизации)

Обнаружена ошибка и исправлена в ответе на авторизацию Microsoft Entra. На этапе /authorize проверки подлинности параметр state из запроса вносится в ответ, чтобы сохранить состояние приложения и помочь предотвратить атаки CSRF. Идентификатор Microsoft Entra неправильно закодировал state параметр, прежде чем вставлять его в ответ, где он был закодирован еще раз. Это приведет к неправильному отклонению ответа от идентификатора Microsoft Entra.

Идентификатор Microsoft Entra больше не будет дублировать этот параметр, позволяя приложениям правильно анализировать результат. Это изменение будет внесено для всех приложений.

Изменяются конечные точки Azure для государственных организаций

Срок вступления в силу: 5 мая 2020 г. (окончание в июне 2020 г.)

Затронутые конечные точки: все

Затронутый протокол: все потоки

1 июня 2018 года официальный центр Microsoft Entra для Azure для государственных организаций изменился на https://login-us.microsoftonline.com https://login.microsoftonline.us. Это изменение также применяется к Microsoft 365 GCC High и DoD, которые также Azure для государственных организаций идентификатора Microsoft Entra. Если имеется приложение в клиенте государственной организации США, необходимо обновить это приложение для входа пользователей в конечной точке .us.

5 мая 2020 г. идентификатор Microsoft Entra id начнет применять изменение конечной точки, блокируя вход пользователей государственных организаций в приложения, размещенные в клиентах правительства США, с помощью общедоступной конечной точки (microsoftonline.com). Затронутые приложения начнут получать ошибку AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Эта ошибка показывает, что приложение пытается войти в систему для пользователей — государственных организаций США в конечной точке общедоступного облака. Если приложение находится в общедоступном облачном клиенте и предназначено для поддержки пользователей — государственных организаций США, необходимо явным образом обновить приложение для их поддержки. Для этого может потребоваться создать новую регистрацию приложения в облаке для государственных организаций США.

Внедрение этого изменения будет осуществляться путем постепенного развертывания с учетом того, как часто пользователи из облака для государственных организаций США входят в приложения. В первую очередь будут охвачены приложения, нечасто используемые пользователями — государственными организациями США, в последнюю очередь — часто используемые. Мы планируем завершить внедрение во всех приложениях в июне 2020 г.

Дополнительные сведения см. в записи блога Azure для государственных организаций, посвященной этой миграции.

Март 2020 г.

Пароли пользователей будут ограничены количеством символов 256.

Срок вступления в силу: 13 марта 2020 г.

Затронутые конечные точки: все

Затронутый протокол: все пользовательские потоки.

Пользователям с паролями дольше 256 символов, которые войдите непосредственно в идентификатор Microsoft Entra (не федеративный поставщик удостоверений, например AD FS), будет предложено изменить пароли, прежде чем они смогут войти. Администраторы могут получать запросы на сброс пароля пользователя.

Ошибка, которая будет фиксироваться в журналах входа, будет аналогична AADSTS 50052: InvalidPasswordExceedsMaxLength.

Сообщение: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Исправление.

Пользователю не удается выполнить вход, поскольку длина пароля превышает максимально допустимую. Он должен обратиться к администратору, чтобы сбросить пароль. Если для клиента включен SSPR, пользователь может сбросить пароль, открыв ссылку "Забыли пароль".

Февраль 2020 г.

К каждому перенаправлению HTTP из конечной точки входа будут добавляться пустые фрагменты.

Дата вступления в силу: 8 февраля 2020 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: потоки OAuth и OIDC, использующие response_type=query, в некоторых случаях охватываются поток кода авторизации, а также неявный поток.

Когда ответ на проверку подлинности отправляется с login.microsoftonline.com в приложение через перенаправление HTTP, служба будет добавлять пустой фрагмент в URL-адрес ответа. Этим путем блокируется класс атаки перенаправления, поскольку браузер гарантированно очищает любой существующий фрагмент в запросе проверки подлинности. Никакие приложения не должны иметь зависимости от данного поведения.

Август 2019

Будет ужесточена семантика формы POST, пробелы и кавычки будут игнорироваться.

Дата вступления в силу: 2 сентября 2019 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: все, где используется POST (учетные данные клиента, активация кода авторизации, ROPC, OBO и активация маркера обновления)

С недели, начинающейся со 2 сентября 2019 г., запросы проверки подлинности, использующие метод POST, будут проверяться с использованием более жестких стандартов HTTP. В частности, пробелы и двойные кавычки (") больше не будут удаляться из значений формы запроса. Эти изменения не должны прерывать существующие клиенты и гарантируют, что запросы, отправленные в идентификатор Microsoft Entra, надежно обрабатываются каждый раз. В будущем (см. выше) мы планируем дополнительно отклонять дублирующиеся параметры и игнорировать в запросах метку порядка байтов.

Пример:

Сейчас ?e= "f"&g=h анализируется так же, как ?e=f&g=h, и поэтому e == f. После внесения этого изменения анализ будет происходить таким образом, что e == "f". Маловероятно, что это будет допустимый аргумент, и запрос будет завершаться ошибкой.

Июль 2019 г.

Маркеры только для приложений, предназначенные для приложений с одним клиентом, будут выдаваться, только если клиентское приложение существует в клиенте ресурса.

Срок вступления в силу: 26 июля 2019 г.

Затронутые конечные точки: версия 1.0 и версия 2.0

Влияние протокола: учетные данные клиента (маркеры только для приложений)

26 июля 2019 г. вступило в силу изменение безопасности, которое меняет способ выдачи маркеров только для приложений (через предоставление учетных данных клиента). Ранее приложениям было разрешено получать маркеры для вызова любого другого приложения независимо от присутствия в клиенте или ролей, имеющих согласие для этого приложения. Это поведение было обновлено таким образом, чтобы для ресурсов (иногда именуемых веб-интерфейсами API) был установлен режим "один клиент" (по умолчанию); клиентское приложение должно существовать в клиенте ресурса. Существующее согласие между клиентом и API по-прежнему не требуется и приложения по-прежнему должны выполнять собственные проверки авторизации, чтобы убедиться, что утверждение roles присутствует и содержит ожидаемое значение для API.

На сегодняшний день в сообщении об ошибке для этого сценария указывается следующее.

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Чтобы устранить эту проблему, используйте интерфейс предоставления согласия администратора для создания в клиенте субъекта — службы клиентского приложения или создайте его вручную. Это требование гарантирует контроль того, что клиент предоставил приложению разрешение на работу в клиенте.

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

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... В этом примере клиент ресурса (центр) — это contoso.com, приложение ресурса — это приложение с одним клиентом под именем gateway.contoso.com/api для клиента Contoso, клиентское приложение — это 00001111-aaaa-2222-bbbb-3333cccc4444. Если у клиентского приложения есть субъект — служба в contoso.com, этот запрос может быть продолжен. Однако если это условие не соблюдается, запрос завершится с ошибкой, описанной выше.

Если приложение шлюза Contoso было мультитенантным приложением, то запрос будет продолжаться независимо от клиентского приложения, имеющего субъект-службу в Contoso.com.

URI перенаправления впредь могут содержать параметры строки запроса

Дата вступления в силу: 22 июля 2019 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: все потоки

Для каждого RFC 6749 приложения Microsoft Entra теперь могут регистрировать и использовать URI перенаправления (ответ) со статическими параметрами запроса (например https://contoso.com/oauth2?idp=microsoft) для запросов OAuth 2.0. Динамические URI перенаправления по-прежнему запрещены, поскольку представляют угрозу безопасности и не могут использоваться для хранения сведений о состоянии в запросе проверки подлинности. Для этого используется параметр state.

Параметр статического запроса подлежит сопоставлению строк URI перенаправления, так же, как и любая другая часть URI перенаправления. Если не зарегистрирована ни одна строка, соответствующая расшифрованному URI redirect_uri, запрос будет отклонен. Если URI найден в регистрации приложения, то для перенаправления пользователя будет использоваться строка полностью, включая параметр статического запроса.

В настоящее время (на конец июля 2019 г.) пользовательский интерфейс регистрации приложений на портале Azure по-прежнему блокирует параметры запроса. Однако можно редактировать манифест приложения вручную, добавляя параметры запроса и тестируя это действие в приложении.

март 2019 г.

Зацикливание клиентов будет прерываться

Дата вступления в силу: 25 марта 2019 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: все потоки

Иногда клиентские приложения могут вести себя некорректно, выдавая сотни одинаковых запросов на вход в течение короткого периода времени. Все эти запросы, независимо от их успешности, приводят к ухудшению качества пользовательского интерфейса и повышению рабочих нагрузок на IDP, увеличению задержек для всех пользователей и снижению доступности IDP. Эти приложения работают за пределами границ обычного использования и должны быть обновлены для достижения корректного поведения.

Клиентам, которые многократно выдают дублирующиеся запросы, будет отправляться invalid_grantошибка: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Большинству клиентов не потребуется изменять поведение, чтобы избежать этой ошибки. Эта ошибка может влиять только на неправильно настроенные клиенты (те, в которые отсутствует кэширование маркеров или уже присутствуют циклические запросы). Клиенты отслеживаются локально, индивидуально по каждому экземпляру (через файл cookie), по следующим факторам.

• Подсказка пользователя, если имеется

• Запрашиваемые области или ресурс

• Client ID

• URI-адрес перенаправления

• Тип и режим ответа

Приложения, выполняющие несколько запросов (более 15) в течение короткого периода времени (5 минут), будут получать сообщение об ошибке invalid_grant, поясняющее, что происходит зацикливание. Запрашиваемые маркеры имеют достаточно длительное время существования (10 минут минимум, 60 минут по умолчанию), и поэтому повторяющиеся запросы в такой промежуток времени не требуются.

Все приложения должны обрабатывать invalid_grant, отображая интерактивную подсказку, а не запрашивать маркер автоматически. Чтобы избежать этой ошибки, клиенты должны убедиться в том, что они правильно кэшируют получаемые маркеры.

2018 октября

Коды авторизации больше нельзя использовать повторно

Дата вступления в силу: 15 ноября 2018 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутый протокол: поток кода.

Начиная с 15 ноября 2018 г. идентификатор Microsoft Entra перестанет принимать ранее используемые коды проверки подлинности для приложений. Это изменение безопасности помогает применить идентификатор Microsoft Entra в соответствии со спецификацией OAuth и будет применяться как для конечных точек версии 1, так и версии 2.

Если ваше приложение повторно использует коды проверки подлинности для получения маркеров для нескольких ресурсов, мы рекомендуем использовать код для получения маркера обновления, а затем использовать этот маркер для получения дополнительных маркеров для других ресурсов. Коды проверки подлинности можно использовать только один раз, однако маркеры обновления можно использовать несколько раз для нескольких ресурсов. Любое новое приложение, которое пытается повторно использовать код проверки подлинности во время потока кода OAuth, получит ошибку invalid_grant.

Дополнительные сведения о маркерах обновления см. в статье Обновление маркеров доступа. При использовании ADAL или MSAL обработку выполняет библиотека — замените второй экземпляр AcquireTokenByAuthorizationCodeAsync на AcquireTokenSilentAsync.

Май-2018

Для потока OBO нельзя использовать маркеры идентификации

Дата: 1 мая 2018 г.

Затронутые конечные точки: версии 1.0 и 2.0.

Затронутые протоколы: неявный поток и поток OBO.

После 1 мая 2018 г. новые приложения не могут использовать маркеры id_token в качестве утверждения в потоке OBO. Вместо этого следует использовать маркеры доступа для защиты API, даже между клиентом и средним уровнем того же приложения. Приложения, зарегистрированные до 1 мая 2018 г., будут дальше работать с возможностью замены маркеров id_token на маркеры доступа, но это нерекомендуемый подход.

Чтобы обойти это изменение, можно сделать следующее.

1. Создайте веб-API для приложения с одной или несколькими областями. Такая явная точка входа позволит обеспечить более точный контроль и защиту.
2. В манифесте вашего приложения, на портале Azure или портале регистрации приложений, убедитесь, что приложению разрешено выдавать маркеры доступа через неявный поток. Это определяется с помощью ключа oauth2AllowImplicitFlow.
3. Когда клиентское приложение запрашивает id_token через response_type=id_token,также запрашивается маркер доступа (response_type=token) для веб-API, созданного выше. Таким образом при использовании конечной точки версии 2.0 параметр scope должен выглядеть примерно так: api://GUID/SCOPE. В конечной точке версии 1.0 параметр resource должен быть универсальным кодом ресурса (URI) приложения веб-API.
4. Передайте этот маркер доступа на средний уровень вместо id_token.