Методы проверки подлинности для интеграции Azure DevOps

сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

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

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

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

Это важно

Рассмотрите возможность использования более безопасных токенов Microsoft Entra по сравнению с более рискованными персональными токенами доступа. Дополнительные сведения см. в разделе "Сокращение использования PAT". Просмотрите рекомендации по проверке подлинности , чтобы выбрать правильный механизм проверки подлинности для ваших потребностей.

Проверка подлинности OAuth 2.0 и Microsoft Entra ID доступна только для служб Azure DevOps, а не для Azure DevOps Server.

Для локальных сценариев используйте клиентские библиотеки .NET, проверка подлинности Windows или персональные маркеры доступа.

Подсказка

Вы можете использовать ИИ, чтобы помочь с этой задачей далее в этой статье или ознакомиться с Включение помощи ИИ с сервером Azure DevOps MCP для начала работы.

Сравнение распространенных вариантов проверки подлинности

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

Метод лучше всего подходит для Положение безопасности Управление учетными данными Работает с Избегайте, когда
Манажируемая идентичность автоматизация Azure размещения, например Функции Azure, служба приложений или виртуальные машины Самый надежный вариант для Azure размещенных рабочих нагрузок, так как маркеры являются короткими и Azure управляет жизненным циклом удостоверений Нет секрета клиента для хранения или поворота; Azure управляет получением удостоверений и маркеров службы Azure DevOps; Azure размещенные рабочие нагрузки в том же клиенте Microsoft Entra после добавления удостоверения в Azure DevOps Рабочая нагрузка не выполняется в Azure или требуется переносимое удостоверение, которое не привязано к ресурсу Azure
Сервис-принципал Автоматизация, которая выполняется вне Azure, в нескольких средах или во внешних системах CI/CD Надежный вариант при использовании проверки подлинности на основе сертификатов или федеративных подходов и применения минимальных привилегий Вы управляете удостоверением приложения и любым секретом клиента или сертификатом, если федеративный поток не удаляет секрет службы Azure DevOps; приложения, скрипты и службы, которым требуется удостоверение приложения Microsoft Entra Вместо этого можно использовать управляемое удостоверение для той же Azure размещенной рабочей нагрузки или средство поддерживает только проверку подлинности на основе PAT.
подключение службы Azure DevOps Azure Pipelines доступ к ресурсам Azure DevOps Надежный вариант для автоматизации конвейеров, так как он использует федерацию удостоверений рабочей нагрузки Microsoft Entra вместо долгосрочных маркеров Azure DevOps управляет подключением к службе, а конвейеры не должны хранить PAT в переменных. Azure DevOps службы; конвейеры, которые обращаются к репозиториям, веб-каналам или REST API в организациях Сценарий не выполняется Azure Pipelines
Личный маркер доступа (PAT) Короткие личные сценарии, однократное тестирование или устаревшие сценарии, которые пока не могут использовать проверку подлинности на основе Microsoft Entra Самый высокий риск распространенных вариантов, так как маркер является долгоживущие секрет носителя, привязанный к учетной записи пользователя. Необходимо создать, сохранить, повернуть и отозвать маркер вручную. Azure DevOps службы и Azure DevOps Server; Интерфейс командной строки, вызовы REST и устаревшие интеграции, поддерживающие PATs Интеграция — это рабочая служба, общая автоматизация или любой сценарий, в котором доступен субъект-служба, управляемое удостоверение или подключение к службе.

Быстрые рекомендации

  • Сначала выберите управляемое удостоверение при запуске рабочей нагрузки на Azure и Azure может принадлежать жизненному циклу удостоверения.
  • Выберите субъект-службу, если требуется удостоверение приложения, но рабочая нагрузка не выполняется в Azure или должна перемещаться по средам.
  • Выберите подключение службы Azure DevOps, если Azure Pipelines необходимо получить доступ к ресурсам Azure DevOps без ПАТ.
  • Выберите pat только для личных, временных, устаревших или Azure DevOps Server сценариев, где более безопасные параметры не применяются.

Методы проверки подлинности по сценарию

Выберите соответствующий метод проверки подлинности на основе типа приложения и требований.

Тип приложения Описание Пример Рекомендуемый способ Примеры кода
Веб-приложения или десктопные приложения Интерактивные приложения с использованием текущих платформ Приложение React, .NET настольное приложение Microsoft Entra OAuth с Microsoft Authentication Library (MSAL) Управляемое консольное приложение клиента
Приложения службы и фоновые приложения Приложения, работающие без взаимодействия с пользователем Функции Azure, фоновые службы Идентификаторы служб и управляемые удостоверения Представители службы
Устаревшие клиентские приложения Существующие приложения, использующие клиентские библиотеки Консольные приложения с библиотеками Azure DevOps .NET .NET клиентские библиотеки с OAuth Консольное приложение клиентской библиотеки
Безголовые приложения/приложения для командной строки Неинтерактивные средства командной строки Создание скриптов, средств автоматизации Поток предоставления авторизации устройства профиль устройства
расширения Azure DevOps Расширения, выполняемые в Azure DevOps Пользовательские виджеты панели мониторинга и формы рабочих элементов пакет SDK веб-расширения Azure DevOps Добавление мини-приложения панели мониторинга
приложения Azure DevOps Server Локальные интеграции Azure DevOps Server Пользовательские расширения сервера .NET клиентские библиотеки или Windows аутентификация Консольное приложение клиентской библиотеки
Личные и нерегламентированные сценарии Быстрые скрипты для личного использования Скрипты PowerShell, команды curl Личные маркеры доступа Начало работы с REST API
Azure Pipelines Доступ к Azure DevOps из конвейера Потребление артефактов из различных организаций подключение службы Azure DevOps Добавить подключение службы Azure DevOps Microsoft Entra

Рекомендации по началу работы

В следующих разделах приведены рекомендации по началу работы в различных сценариях.

Новые приложения

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

Существующие приложения

  • План миграции с персональных токенов доступа на аутентификацию Microsoft Entra ID.
  • Рассмотрите шкалу миграции аутентификации для улучшения процесса в Azure DevOps и снижения использования токенов личного доступа.
  • Сравните ваш нынешний подход к проверке подлинности с лучшими практиками безопасности.

Azure DevOps Server

  • Используйте .NET клиентские библиотеки, если возможно, с Windows аутентификацией.
  • Используйте личные маркеры доступа для сценариев Azure DevOps Server, если они приемлемы.
  • Запланируйте миграцию будущих служб Azure DevOps, чтобы воспользоваться преимуществами современной проверки подлинности.

Часто задаваемые вопросы (FAQ)

Следует ли использовать OAuth токены Microsoft Entra ID или личные токены доступа?

Используйте Microsoft Entra ID OAuth в следующих сценариях:

  • Новые приложения и интеграции.
  • Рабочие нагрузки, требующие надежной безопасности.
  • Приложения, которым требуется корпоративная идентификация.
  • Долгосрочные проекты с требованиями соответствия требованиям.

Используйте личные маркеры доступа только в следующих сценариях:

  • Личные сценарии и нерегламентированные задачи.
  • Устаревшие приложения во время планирования миграции.
  • В сценариях Azure DevOps Server, в которых современная аутентификация недоступна.

Следует ли использовать учетные записи служб или делегирование пользователей для аутентификации?

Используйте основные учетные данные службы или управляемые удостоверения в следующих сценариях:

  • Создавайте приложения, которые работают независимо (фоновые службы, автоматизация).
  • Создание приложений, которые не требуют взаимодействия с пользователем.
  • Реализуйте обмен данными между службами.
  • Создание конвейеров непрерывной интеграции и непрерывной доставки (CI/CD) или автоматизированных рабочих процессов.

Используйте делегирование пользователей (OAuth с согласием пользователя) в следующих сценариях:

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

Как выполнить проверку подлинности с помощью служб Azure DevOps и Azure DevOps Server?

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

  • Azure DevOps Services: используйте Microsoft Entra ID OAuth.
  • Azure DevOps Server. Используйте клиентские библиотеки .NET с Windows аутентификацией или личными маркерами доступа.

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

Почему служебная учетная запись не может получить доступ к API Azure DevOps?

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

  • Учетная запись службы не "материализована": используйте правильный метод входа. Для учетных записей служб требуются разрешения интерактивного входа или правильная регистрация Microsoft Entra ID.
  • Insufficient permissions: Убедитесь, что у учетной записи службы есть достаточные разрешения Azure DevOps.
  • Метод проверки подлинности: используйте служебные принципы или управляемые идентификационные объекты вместо попыток пройти аутентификацию как учетная запись службы.

Как мигрировать с личных токенов доступа на современную проверку подлинности?

Выполните следующие действия:

  1. Определите текущее использование маркера личного доступа в приложениях.

  2. Выберите альтернативный метод проверки подлинности:

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

  3. Обновите код проверки подлинности, используя образцы проверки подлинности для миграции Azure DevOps.

  4. Тщательно протестируйте изменения перед удалением зависимостей токена личного доступа.

  5. Отслеживайте и проверяйте новый метод проверки подлинности.

Почему не следует декодировать или читать декларации из токенов аутентификации?

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

Утверждения токенов никогда не документируются публично, и Azure DevOps оставляет за собой право изменять, переименовывать, удалять или шифровать их в любое время без уведомления. Начиная с лета 2025 года Azure DevOps дополнительно шифрует токены аутентификации, что означает, что клиенты не могут читать их содержимое. Любое приложение, которое декодирует токены для извлечения утверждений, выходит из строя.

Вместо анализа токенов следуйте следующим рекомендациям.

  • Обрабатывать токены как не подлежащие анализу — передавать их в заголовки авторизации, но не декодировать или анализировать их.
  • Использовать поддерживаемые REST API — извлеките данные пользователя или организации из Azure DevOps REST API, которые предоставляют стабильные контракты и документацию.
  • Предположим, что любое утверждение может измениться — если вы обнаружите, что вы анализируете содержимое токена, чтобы считать значения, поместите эту логику в вызов API.

Эти изменения не влияют на приложения, которые уже рассматривают маркеры как непрозрачные.

Процедуры реализации

Выбрав метод проверки подлинности для вашего сценария, выполните действия по реализации:

Использование ИИ для выбора метода проверки подлинности

Если вы подключаете Azure DevOps MCP Server к агенту ИИ в режиме агента, вы можете использовать запросы естественного языка для получения рекомендаций по проверке подлинности для вашего сценария.

задачи Пример запроса
Выбор аутентификации для фоновой службы Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs?
Сравнение параметров проверки подлинности Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration
Проверка подлинности для веб-приложения I'm building a React web app that needs to access Azure DevOps on behalf of signed-in users — what authentication approach should I use?
Переход с использования личных токенов доступа (PATs) Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations
Проверка подлинности для CI/CD What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow?
Устранение сбоев аутентификации I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue

Замечание

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

Связанный контент

  • Last updated on