Поделиться через

Создание azure DevOps с помощью microsoft Entra Приложение OAuth

  • Статья

Внимание

При создании нового приложения OAuth 2.0 начните с приложений Microsoft Entra OAuth, так как приложения OAuth для Azure DevOps OAuth планируются для отмены в 2026 году. Дополнительные сведения см. в записи блога.

Microsoft Entra ID OAuth

Идентификатор Microsoft Entra — это отдельный продукт Майкрософт с собственной платформой. В Microsoft Entra вы можете зарегистрировать приложение для доступа к клиентам Azure и определить разрешения, необходимые для ресурсов Azure, из которых Azure DevOps считается одним.

Приложения Microsoft Entra и приложения Azure DevOps являются отдельными сущностями без знания друг друга. Это средство проверки подлинности приложения отличается от Microsoft Entra OAuth до Azure DevOps OAuth. Для одной из них приложения OAuth идентификатора Microsoft Entra выдают маркеры Microsoft Entra, а не маркеры доступа Azure DevOps. Эти маркеры имеют стандартную продолжительность в один час до истечения срока действия.

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

Зачем выбрать Microsoft Entra?

В качестве ведущего поставщика управления удостоверениями и доступом (IAM) идентификатор Microsoft Entra ориентирован на потребности компаний, которым необходимо управлять участниками группы и защищать ресурсы компании. Идентификатор Microsoft Entra предлагает множество функций. Разработка приложений и управление ими является одним из них. Модель приложения Microsoft Entra предлагает несколько преимуществ по сравнению с моделью приложения OAuth Azure DevOps, что делает их более привлекательными для разработчиков приложений.

1. Более широкий охват внутри и за пределами Корпорации Майкрософт

Создав приложение в Microsoft Entra, у вас есть более широкий доступ к остальной части экосистемы Майкрософт. Одно приложение Microsoft Entra можно использовать для доступа к нескольким продуктам Майкрософт, что упрощает управление учетными данными приложений. Teams, предлагающие продукты SaaS, могут рассмотреть возможность создания предварительно созданного приложения, которое отображается вместе с другими популярными приложениями в коллекции приложений Microsoft Entra.

2. Больше видимости администратора, согласия и управления

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

3. Более жесткие элементы управления условным доступом

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

4. Конфигурация самостоятельного приложения

Изменение областей приложений и владение приложениями в приложении Microsoft Entra является относительным ветерком по сравнению с приложениями OAuth Azure DevOps. Разработчики приложений обращаются к нашей группе поддержки клиентов, чтобы внести изменения в приложения OAuth Azure DevOps, но в Microsoft Entra возможность изменения областей возвращается разработчику. Владение приложениями может даже предоставляться нескольким пользователям и не ограничиваться одним пользователем, что может поставить проблему, если пользователь покидает компанию в будущем.

5. Доступные журналы входа

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

Полезные ресурсы

Создание новой платформы может быть подавляющим. Мы предоставляем некоторые полезные ссылки, которые мы считаем полезными для процесса разработки приложений OAuth в Microsoft Entra. Для разработчиков, переход с Azure DevOps OAuth на Microsoft Entra OAuth, мы предоставляем полезные советы, которые следует учитывать во время миграции.

Хорошие ресурсы для разработчиков

Хорошие ресурсы для администраторов

Советы по созданию и переносу

Примечание.

Приложения Microsoft Entra OAuth изначально не поддерживают пользователей MSA для REST API Azure DevOps. Если вы создаете приложение, которое должно обслуживать пользователей MSA или поддерживает пользователей Microsoft Entra и MSA, приложения OAuth Azure DevOps остаются лучшим вариантом. В настоящее время мы работаем над собственной поддержкой пользователей MSA через Microsoft Entra OAuth.

  • Хорошо известные идентификаторы Azure DevOps:
    • Идентификатор ресурса Microsoft Entra: 499b84ac-1321-427f-aa17-267ca6975798
    • Uri ресурса: https://app.vssps.visualstudio.com
    • .default Используйте область при запросе маркера со всеми областями, для которыми разрешено приложение.
  • При миграции существующего приложения можно использовать идентификаторы пользователей Azure DevOps, которые не существуют в Microsoft Entra. Используйте API ReadIdentities для разрешения и сопоставления различных удостоверений, используемых каждым поставщиком удостоверений.

Потоки только для приложений в Microsoft Entra

Microsoft Entra OAuth — это рекомендуемое решение для создания приложений для доступа к службам Azure DevOps от имени пользователя с согласием.

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