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

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

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

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

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

Это важно

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

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

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

Подсказка

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

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

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

Тип приложения Описание Пример Рекомендуемый способ Примеры кода
Веб-приложения или десктопные приложения Интерактивные приложения с использованием текущих платформ Приложение React, .NET настольное приложение Microsoft Entra OAuth с Microsoft Authentication Library (MSAL) Управляемое консольное приложение клиента
Приложения службы и фоновые приложения Приложения, работающие без взаимодействия с пользователем Azure Functions, фоновые службы Идентификаторы служб и управляемые удостоверения Представители службы
Устаревшие клиентские приложения Существующие приложения, использующие клиентские библиотеки Консольные приложения с библиотеками 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 DevOps с приложениями Microsoft Entra OAuth для наилучшей безопасности и совместимости в будущем.
  • Используйте главные службы или управляемые идентификаторы для сценариев взаимодействия между службами.
  • Избегайте личных маркеров доступа в рабочих приложениях.

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

  • Спланировать миграцию с персональных токенов доступа на аутентификацию 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 Используйте метод для обнаружения типа службы и применения соответствующего метода проверки подлинности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

задачи Пример запроса
Выбор аутентификации для фоновой службы 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