Utiliser Azure DevOps OAuth 2.0

Azure DevOps Services

Cet article explique comment Azure DevOps OAuth 2.0 fonctionne pour les applications existantes et fournit des conseils pour la maintenance et la migration de vos applications.

Aperçu

Azure DevOps OAuth 2.0 permet aux applications d’accéder aux ressources Azure DevOps pour le compte des utilisateurs. Bien que ce service soit déconseillé, les applications existantes continuent de fonctionner jusqu’en 2026.

Recommandation de migration : commencez à planifier votre migration vers Microsoft Entra ID OAuth pour garantir un service et un accès continus aux fonctionnalités de sécurité améliorées.

Conditions préalables

Avant d’utiliser des applications OAuth Azure DevOps :

Utilisation d’applications OAuth Azure DevOps existantes

1. Gérer votre inscription d’application existante

Pour les applications existantes, vous pouvez afficher et gérer les paramètres de votre application :

1. Accédez à votre profil Visual Studio pour accéder à vos inscriptions d’application.

2. Passez en revue vos étendues configurées et vérifiez qu’elles correspondent aux besoins de votre application.

3. Vérifiez la configuration de votre URL de rappel et mettez à jour si nécessaire.

   

4. Planifiez votre calendrier de migration vers Microsoft Entra ID OAuth avant l’échéance de dépréciation de 2026.

2. Autoriser votre application

Le flux d’autorisation reste le même pour les applications OAuth Azure DevOps existantes :

1. Diriger les utilisateurs vers l’URL d’autorisation avec les paramètres de votre application :

   https://app.vssps.visualstudio.com/oauth2/authorize
           ?client_id={app ID}
           &response_type=Assertion
           &state={state}
           &scope={scope}
           &redirect_uri={callback URL}
   

   Paramètre	Type	Descriptif
   client_id	GUID	ID affecté à votre application lors de son inscription
   response_type	chaîne	Doit être Assertion
   state	chaîne	Valeur de chaîne générée qui met en corrélation le rappel avec sa requête d’autorisation
   scope	chaîne	Étendues inscrites auprès de l’application, séparées par des espaces. Voir les étendues disponibles
   redirect_uri	URL	URL de rappel de votre application. Doit correspondre exactement à l’URL inscrite auprès de l’application

   Exemple d’URL d’autorisation :

   https://app.vssps.visualstudio.com/oauth2/authorize
           ?client_id=00001111-aaaa-2222-bbbb-3333cccc4444
           &response_type=Assertion
           &state=User1
           &scope=vso.work%20vso.code_write
           &redirect_uri=https://fabrikam.azurewebsites.net/myapp/oauth-callback
   

   Après l’autorisation de l’utilisateur, Azure DevOps redirige vers votre URL de rappel avec le code d’autorisation :

   https://fabrikam.azurewebsites.net/myapp/oauth-callback
           ?code={authorization code}
           &state=User1
   

3. Code d’autorisation Exchange pour le jeton d’accès

Utilisez le code d’autorisation pour demander un jeton d’accès et actualiser le jeton :

Détails de la requête

URL

POST https://app.vssps.visualstudio.com/oauth2/token

En-têtes

Content-Type: application/x-www-form-urlencoded

Corps de la demande

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={1}&redirect_uri={2}

Substitution de paramètre :

• {0}: secret client encodé en URL à partir de l'enregistrement de l'application
• {1}: code d’autorisation encodé en URL depuis le "callback"
• {2}: URL de rappel inscrite auprès de l’application

Exemple d’implémentation C#

public string GenerateRequestPostData(string appSecret, string authCode, string callbackUrl)
{
   return String.Format("client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={1}&redirect_uri={2}",
               HttpUtility.UrlEncode(appSecret),
               HttpUtility.UrlEncode(authCode),
               callbackUrl
        );
}

Réponse

{
    "access_token": "{ access token for the user }",
    "token_type": "{ type of token }",
    "expires_in": "{ time in seconds that the token remains valid }",
    "refresh_token": "{ refresh token to use to acquire a new access token }"
}

4. Utiliser le jeton d’accès

Incluez le jeton d’accès en tant que jeton du porteur dans vos demandes d’API :

Format d’en-tête d’autorisation :

Authorization: Bearer {access_token}

Exemple de demande d’API :

GET https://dev.azure.com/myaccount/myproject/_apis/build-release/builds?api-version=3.0
Authorization: Bearer {access_token}

5. Actualiser les jetons d’accès expirés

Lorsque les jetons d’accès expirent, utilisez le jeton d’actualisation pour obtenir un nouveau jeton d’accès :

Requête :

POST https://app.vssps.visualstudio.com/oauth2/token
Content-Type: application/x-www-form-urlencoded
Content-Length: 1654

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={0}&grant_type=refresh_token&assertion={1}&redirect_uri={2}

Substitution de paramètre :

• {0}: clé secrète du client encodée en URL
• {1}: jeton d’actualisation encodé par URL
• {2}: URL de rappel inscrite auprès de l’application

Réponse :

{
    "access_token": "{ new access token }",
    "token_type": "{ type of token }",
    "expires_in": "{ time in seconds that the token remains valid }",
    "refresh_token": "{ new refresh token }"
}

Exemples de code

Vous trouverez des exemples de travail dans notre référentiel d’exemples d’authentification Azure DevOps.

Gestion des secrets d’application

Les applications Azure DevOps OAuth prennent en charge les secrets doubles pour permettre une rotation sans interruption :

Faire pivoter les clés secrètes

1. Générez un nouveau secret dans votre profil Visual Studio ou via les API de secret d’inscription.

   

2. Confirmez l’action dans la boîte de dialogue modale.

   

3. Mettez à jour votre application pour utiliser le nouveau secret avant l’expiration de l’ancien.

4. Testez soigneusement le nouveau secret avant l’expiration de l’ancien secret.

5. Répétez le processus lorsque le nouveau secret approche de l’expiration.

Révocation de secrets d’urgence

Si un secret est compromis :

1. Régénérer immédiatement le secret dans votre profil.
2. Mettez à jour votre application avec le nouveau secret.
3. Surveillez l’accès non autorisé dans les journaux de votre application.

Supprimer votre application

Pour supprimer une application OAuth Azure DevOps :

1. Accédez à votre profil Visual Studio.

2. Sélectionnez le locataire approprié dans le menu déroulant.

3. Recherchez votre application sous Applications et services.

4. Sélectionnez Supprimer dans la page d’inscription de l’application.

   

5. Confirmez la suppression dans la boîte de dialogue modale.

Après la suppression, l’application et tous ses jetons d'authentification cessent de fonctionner immédiatement.

Planification de migration

Liste des éléments à vérifier pour la migration

• [ ] Consulter la documentation OAuth de Microsoft Entra ID
• [ ] Identifier toutes les applications à l’aide d’Azure DevOps OAuth dans votre organisation
• [ ] Planifier la chronologie de la migration , ce qui permet un temps de test adéquat
• [ ] Mettre à jour l’architecture d’application pour prendre en charge Microsoft Entra ID OAuth
• [ ] Tester la migration dans un environnement hors production
• [ ] Communiquer les modifications aux utilisateurs et aux parties prenantes
• [ ] Effectuer la migration avant l’échéance 2026

Avantages de la migration

Fonctionnalités de sécurité améliorées :

• Prise en charge de l’authentification multifacteur
• Stratégies d’accès conditionnel
• Détection avancée des menaces
• Intégration des identités d’entreprise

Meilleure expérience pour les développeurs :

• Bibliothèques d’authentification modernes (MSAL)
• Plateforme d’identité cohérente entre les services Microsoft
• Meilleure gestion et mise en cache des jetons

Prise en charge à long terme :

• Développement continu des investissements et fonctionnalités
• Fonctionnalités de conformité et de gouvernance d’entreprise

Questions fréquentes

Q : Puis-je toujours créer des applications OAuth Azure DevOps ?

R : Non. Les nouvelles inscriptions d’applications ont cessé en avril 2025. Utilisez l’ID OAuth Microsoft Entra pour les nouvelles applications.

Q : Quand mon application OAuth Azure DevOps existante cessera-t-elle de fonctionner ?

R : Les applications existantes continuent de fonctionner jusqu’à ce qu’Azure DevOps OAuth soit entièrement déconseillé en 2026. Planifiez votre migration bien avant cette échéance.

Q : Puis-je utiliser OAuth avec des applications mobiles ?

R : Azure DevOps OAuth prend uniquement en charge le flux de serveur web et nécessite un stockage sécurisé des secrets client, ce qui le rend inadapté aux applications mobiles. Microsoft Entra ID OAuth offre une meilleure prise en charge des applications mobiles.

Q : Que dois-je faire si j’obtiens une erreur HTTP 400 lors de la demande de jetons ?

R : Causes courantes :

• En-tête incorrect Content-Type (doit être application/x-www-form-urlencoded)
• Paramètres de corps de requête mal formés
• Code d’autorisation non valide ou expiré
• URL de rappel incompatible

Q : Pourquoi obtenir des erreurs HTTP 401 avec des jetons OAuth, mais pas avec des PAT ?

R : Vérifiez si l’administrateur de votre organisation a désactivé l’accès aux applications tierces via OAuth à l’adresse suivante : https://dev.azure.com/{your-org-name}/_settings/organizationPolicy

En cas de désactivation, les flux d’autorisation OAuth fonctionnent, mais les appels d’API retournent TF400813: The user "<GUID>" is not authorized to access this resource.

Q : Puis-je utiliser localhost pour les tests ?

A : Oui. Azure DevOps OAuth supporte les URL de rappel https://localhost pour le développement et les tests locaux.

Q : Comment gérer les refus d’autorisation et les révocations ?

R : Implémentez une gestion des erreurs appropriée pour :

• Déni d’autorisation : aucun code d’autorisation n’est retourné dans le rappel
• Autorisation révoquée : les appels d’API retournent des erreurs 401 ; demander une autorisation de nouveau à l’utilisateur

Q : Quelle est la différence entre Azure DevOps OAuth et Microsoft Entra ID OAuth ?

A :

• Azure DevOps OAuth : déconseillé, fonctionnalités de sécurité limitées spécifiques à Azure DevOps
• Microsoft Entra ID OAuth : Sécurité moderne, professionnelle, renforcée, support à long terme

Étapes suivantes

Pour les applications existantes :

Pour les nouvelles applications :

Contenu connexe

• Choisir votre méthode d’authentification
• Migrer vers Microsoft Entra ID OAuth
• Passer en revue les étendues OAuth 2.0 pour Azure DevOps
• Gérer les autorisations d’application
• Explorer la référence de l'API REST Azure DevOps
• En savoir plus sur la sécurité et l’identité dans Azure DevOps