Méthodes d’authentification pour les intégrations de Azure DevOps

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Cet article se concentre sur les modèles d’authentification d’intégration pour les applications, les scripts et les pipelines qui appellent Azure DevOps. Utilisez l’authentification moderne Microsoft Entra ID basée sur les nouvelles intégrations, car elle offre une sécurité plus forte et une meilleure compatibilité à long terme.

Si vous avez besoin d’une vue d’ensemble au niveau de l’organisation qui couvre la connexion utilisateur, les contrôles de gouvernance et la posture de sécurité au niveau de la plateforme, consultez les instructions d’authentification pour Azure DevOps.

Utilisez Microsoft Entra ID authentification pour les nouvelles applications qui s’intègrent à Azure DevOps Services. Utilisez des jetons d'accès personnels avec parcimonie, et uniquement lorsque Microsoft Entra ID n'est pas disponible.

Important

Envisagez d’utiliser des jetons Microsoft Entra, qui sont plus sécurisés, plutôt que des jetons d’accès personnels. Pour plus d’informations, consultez Réduire l’utilisation de PAT. Passez en revue les conseils d’authentification pour choisir le mécanisme d’authentification approprié pour vos besoins.

L’authentification OAuth 2.0 et Microsoft Entra ID est disponible uniquement pour les services Azure DevOps, pas Azure DevOps Server.

Pour les scénarios locaux, utilisez .NET bibliothèques clientes, Authentification Windows ou jetons d’accès personnels.

Conseil / Astuce

Vous pouvez utiliser l’IA pour faciliter cette tâche plus loin dans cet article, ou voir Enable AI assistance avec Azure DevOps MCP Server pour commencer.

Comparer les choix d’authentification courants

Utilisez le tableau suivant pour comparer les choix d’authentification les plus courants pour les applications, les scripts et les pipelines.

Method Idéal pour Posture de sécurité Gestion des informations d’identification Fonctionne avec Éviter quand
Identité gérée automatisation Azure hébergée, telle que Azure Functions, App Service ou machines virtuelles Option la plus forte pour les charges de travail hébergées Azure, car les jetons sont de courte durée et Azure gère le cycle de vie des identités Aucune clé secrète client pour stocker ou faire pivoter ; Azure gère l’acquisition d’identité et de jeton services Azure DevOps ; charges de travail hébergées Azure dans le même locataire Microsoft Entra après avoir ajouté l’identité à Azure DevOps La charge de travail ne s'exécute pas sur Azure, ou vous avez besoin d'une identité portable qui n'est pas liée à une ressource Azure
Service Principal Automatisation qui s’exécute en dehors de Azure, dans plusieurs environnements ou dans des systèmes CI/CD externes Option forte lorsque vous utilisez des approches d’authentification basées sur un certificat ou fédérées et appliquez des privilèges minimum Vous gérez l’identité de l’application et tout certificat ou secret client, sauf si un flux fédéré supprime le secret Azure DevOps Services ; applications, scripts et services qui ont besoin d’une identité d’application Microsoft Entra Vous pouvez utiliser une identité managée à la place pour la même charge de travail hébergée par Azure, ou l’outil prend uniquement en charge l’authentification basée sur pat
connexion de service Azure DevOps Azure Pipelines l’accès aux ressources Azure DevOps Option forte pour l’automatisation du pipeline, car elle utilise Microsoft Entra fédération d’identité de charge de travail au lieu de jetons de longue durée Azure DevOps gère la connexion de service et les pipelines n'ont pas besoin de stocker des paT dans des variables Azure DevOps Services ; pipelines qui accèdent aux dépôts, flux ou API REST au sein des organisations Le scénario ne s'exécute pas via Azure Pipelines
Jeton d’accès personnel (PAT) Scripts personnels de courte durée, tests ponctuels ou scénarios hérités qui ne peuvent pas encore utiliser l'authentification basée sur Microsoft Entra Risque le plus élevé des choix courants, car le jeton est un secret porteur de longue durée lié à un compte d’utilisateur Vous devez créer, stocker, faire pivoter et révoquer le jeton manuellement Azure DevOps Services et Azure DevOps Server ; CLI, appels REST et intégrations héritées qui prennent en charge les PAT L’intégration est un service de production, une automatisation partagée ou tout scénario dans lequel un principal de service, une identité managée ou une connexion de service est disponible

Recommandations rapides

  • Choisissez d’abord l’identité managée lorsque la charge de travail s’exécute sur Azure et que Azure pouvez posséder le cycle de vie des identités.
  • Choisissez un principal de service lorsque vous avez besoin d'une identité d'application, mais que la charge de travail ne s'exécute pas sur Azure ou doit se déplacer entre les environnements.
  • Choisissez une connexion de service Azure DevOps lorsque Azure Pipelines devez accéder à des ressources Azure DevOps sans pater.
  • Choisissez un PAT uniquement pour les scénarios personnels, temporaires, hérités ou Azure DevOps Server où les options plus sécurisées ne s'appliquent pas.

Méthodes d’authentification par scénario

Choisissez la méthode d’authentification appropriée en fonction du type et des exigences de votre application.

Type d’application Descriptif Exemple Méthode recommandée Exemples de code
Applications web/de bureau Applications interactives utilisant des frameworks actuels Application React, application de bureau .NET Microsoft Entra OAuth avec le Microsoft Authentication Library (MSAL) Application console client gérée
Applications de service/d’arrière-plan Applications s’exécutant sans interaction utilisateur Azure Functions, services en arrière-plan Principaux de service et identités managées Principaux de service
Applications clientes héritées Applications existantes utilisant des bibliothèques clientes Applications console avec des bibliothèques Azure DevOps .NET Bibliothèques .NET clientes avec OAuth application console de bibliothèque Client
Applications sans tête/CLI Outils en ligne de commande non interactifs Générer des scripts, des outils d’automatisation Flux d’octroi d’autorisation d’appareil Profil d'appareil
Extensions Azure DevOps Extensions s’exécutant dans Azure DevOps Widgets de tableau de bord personnalisés et formulaires d’éléments de travail SDK d’extension web Azure DevOps Ajouter un widget de tableau de bord
Les applications Azure DevOps Server Intégrations locales Azure DevOps Server Extensions de serveur personnalisées bibliothèques clientes .NET ou authentification Windows application console de bibliothèque Client
Scripts personnels/ad hoc Scripts rapides pour une utilisation personnelle Scripts PowerShell, commandes curl Jetons d’accès personnels Commencez avec les API REST
Azure Pipelines Accéder Azure DevOps à partir d’un pipeline Consommer des artefacts de différentes organisations connexion de service Azure DevOps Ajouter une connexion de service Microsoft Entra Azure DevOps

Suggestions pour bien commencer

Les sections suivantes fournissent des recommandations pour commencer dans différents scénarios.

Nouvelles applications

  • Construisez des intégrations Azure DevOps avec des applications OAuth de Microsoft Entra pour une meilleure sécurité et une compatibilité future optimale.
  • Utilisez des principaux de service ou des identités managées pour les scénarios de service à service.
  • Évitez les jetons d’accès personnels dans les applications de production.

Applications existantes

  • Planifiez la migration des jetons d'accès personnels vers l'authentification Microsoft Entra ID.
  • Considérez la chronologie de migration d'authentification pour les améliorations d'Azure DevOps et réduire la nécessité de l'utilisation de jetons d'accès personnels.
  • Passez en revue votre approche d’authentification actuelle par rapport aux meilleures pratiques de sécurité.

Azure DevOps Server

  • Utilisez .NET bibliothèques clientes avec l’authentification Windows lorsque cela est possible.
  • Utilisez des jetons d'accès personnels pour Azure DevOps Server scénarios lorsqu'ils sont acceptables.
  • Planifiez la migration future de Azure DevOps Services pour tirer parti de l’authentification moderne.

Questions fréquemment posées (FAQ)

Dois-je utiliser OAuth avec Microsoft Entra ID ou des jetons d'accès personnels ?

Utilisez Microsoft Entra ID OAuth dans les scénarios suivants :

  • Nouvelles applications et intégrations.
  • Charges de travail de production nécessitant une sécurité robuste.
  • Applications qui ont besoin d’une intégration d’identité d’entreprise.
  • Projets à long terme avec des exigences de conformité.

Utilisez des jetons d’accès personnels uniquement dans les scénarios suivants :

  • Scripts personnels et tâches ad hoc.
  • Applications héritées pendant la planification de la migration.
  • Azure DevOps Server scénarios où l'authentification moderne n'est pas disponible.

Dois-je utiliser des identifiants de service ou une délégation d'utilisateur pour l'authentification ?

Utilisez des principaux de service ou des identités managées dans les scénarios suivants :

  • Créez des applications qui fonctionnent indépendamment (services en arrière-plan, automatisation).
  • Créez des applications qui ne nécessitent pas d’interaction utilisateur.
  • Implémentez la communication de service à service.
  • Créez des pipelines d’intégration continue et de livraison continue (CI/CD) ou des flux de travail automatisés.

Utilisez la délégation d’utilisateur (OAuth avec consentement de l’utilisateur) dans les scénarios suivants :

  • Créez des applications qui agissent pour les utilisateurs humains.
  • Créez des applications interactives où les utilisateurs se connectent avec leurs propres informations d’identification.
  • Implémentez des fonctionnalités qui nécessitent des autorisations spécifiques à l’utilisateur.
  • Créez des applications qui respectent les droits d’accès individuels des utilisateurs.

Comment s’authentifier auprès des services Azure DevOps et des Azure DevOps Server ?

Créez des chemins d’authentification distincts pour chaque service :

  • Azure DevOps Services : utilisez Microsoft Entra ID OAuth.
  • Azure DevOps Server : utilisez des bibliothèques clientes .NET avec des jetons d’accès personnels ou d’authentification Windows.

Utilisez la requestContext méthode pour détecter le type de service et appliquer la méthode d’authentification appropriée.

Pourquoi mon compte de service ne peut-il pas accéder aux API Azure DevOps ?

Voici quelques problèmes courants qui affectent l’accès au compte de service :

  • Compte de service non « matérialisé » : utilisez la méthode de connexion correcte. Les comptes de service ont besoin d’autorisations de connexion interactives ou d’une inscription appropriée Microsoft Entra ID.
  • Autorisations insuffisantes : vérifiez que le compte de service dispose des autorisations appropriées sur Azure DevOps.
  • Méthode d’authentification : utilisez des principaux de service ou des identités managées au lieu d’essayer de s’authentifier en tant que compte de service.

Comment migrer des jetons d’accès personnels vers l’authentification moderne ?

Suivez ces étapes :

  1. Identifiez l’utilisation actuelle des jetons d’accès personnels dans vos applications.

  2. Choisissez une autre méthode d’authentification :

    • Microsoft Entra ID OAuth pour les scénarios délégués par l’utilisateur
    • Principaux de service pour les scénarios de service à service
    • connexion de service Azure DevOps

  3. Mettez à jour le code d’authentification à l’aide des exemples d’authentification de migration Azure DevOps.

  4. Testez soigneusement les modifications avant de supprimer les dépendances de jetons d’accès personnels.

  5. Surveillez et validez la nouvelle méthode d’authentification.

Pourquoi ne dois-je pas décoder ou lire des revendications à partir de jetons d’authentification ?

Les jetons d’authentification existent uniquement pour prouver qui est l’appelant et ce qu’il est autorisé à faire. Ils ne sont pas une interface de données stable ou un schéma dont vous pouvez dépendre.

Les revendications de jeton ne sont jamais documentées publiquement et Azure DevOps se réserve le droit de modifier, renommer, supprimer ou chiffrer ces revendications à tout moment sans préavis. À compter de l'été 2025, Azure DevOps chiffre davantage les jetons d'authentification, ce qui signifie que les clients ne peuvent pas lire les charges utiles des jetons. Toute application qui décode des jetons pour extraire des informations tombe en panne.

Au lieu de lire les informations du jeton, suivez ces pratiques :

  • Traitez les jetons comme opaques : transmettez-les dans les en-têtes d’autorisation, mais ne les décodez pas ou ne les inspectez pas.
  • Utilisez les API REST prises en charge : récupérez les données utilisateur ou organisation à partir de Azure DevOps API REST, qui fournissent des contrats et une documentation stables.
  • Supposons que n’importe quelle revendication peut changer : si vous vous trouvez vous-même à analyser le contenu du jeton pour lire des valeurs, placez cette logique dans un appel d’API à la place.

Ces modifications n’affectent pas les applications qui traitent déjà les jetons comme opaques.

Procédures d’implémentation

Après avoir choisi la méthode d’authentification pour votre scénario, effectuez les étapes d’implémentation :

Utiliser l’IA pour choisir une méthode d’authentification

Si vous connectez le Azure DevOps MCP Server à votre agent IA en mode agent, vous pouvez utiliser des invites en langage naturel pour obtenir des recommandations d’authentification pour votre scénario.

Tâche Exemple d’invite
Choisir auth pour un service en arrière-plan Which authentication method should I use for a background Azure Function that needs to access Azure DevOps APIs?
Comparer les options d’authentification Help me choose between service principals, managed identities, and personal access tokens for my Azure DevOps integration
Authentification pour une application web 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?
Migrer depuis PAT (tokens d'accès personnel) Help me plan a migration from personal access tokens to Microsoft Entra ID authentication for my Azure DevOps integrations
Authentification pour CI/CD What's the most secure way to authenticate Azure DevOps REST API calls from a GitHub Actions workflow?
Résoudre les échecs d’authentification I'm getting 401 errors when calling the Azure DevOps REST API with my token — help me diagnose the issue

Note

Le mode agent et le serveur MCP utilisent le langage naturel. Vous pouvez donc ajuster ces invites ou poser des questions de suivi pour affiner les résultats.

Contenu connexe

  • Last updated on