For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navigation principale
Theme

Configuration de la fédération d’identités de charge de travail pour Microsoft Azure

Vous pouvez utiliser Microsoft Azure comme fournisseur d’identités de charge de travail dans deux cas :

  • Identité managée Azure : échangez un jeton d’accès Microsoft Entra ID émis pour une identité managée contre un jeton d’accès OpenAI de courte durée.
  • AKS : échangez un jeton projeté de compte de service Azure Kubernetes Service (AKS) contre un jeton d’accès OpenAI de courte durée.

Identité managée Azure

Les identités managées Azure permettent aux charges de travail hébergées sur Azure de demander des jetons Microsoft Entra sans stocker de secrets de longue durée. Dans le cadre de la fédération d’identités de charge de travail OpenAI, le jeton de l’identité managée sert de jeton du sujet. OpenAI le valide avant d’émettre un jeton d’accès OpenAI.

Configuration de l’identité managée Azure

Dans Microsoft Entra, créez ou utilisez une inscription d’application qui représente l’audience de jetons à laquelle OpenAI doit faire confiance. Configurez son URI d’ID d’application. Cet URI correspond à la valeur resource que votre charge de travail transmet au service de métadonnées d’instance Azure (IMDS). Il figure dans la revendication aud du jeton émis. Pour effectuer cette configuration côté Microsoft, consultez le guide Microsoft Entra pour créer une application Entra ID et un principal de service.

L’URI d’ID d’application configuré dans Microsoft Entra ID, le paramètre resource d’IMDS, la revendication aud du jeton obtenu et l’audience du fournisseur d’identités de charge de travail configuré dans OpenAI doivent tous avoir la même valeur.

Créez une identité managée, puis attribuez-la à la ressource Azure qui exécute votre application, par exemple une machine virtuelle. La ressource doit pouvoir appeler IMDS pendant l’exécution. Pour plus de détails sur la configuration d’Azure, consultez la présentation des identités managées de Microsoft et les instructions d’attribution d’une identité dans la documentation de la ressource Azure concernée.

Obtention d’un jeton d’identité managée Azure

Depuis la ressource Azure à laquelle vous avez attribué l’identité managée, demandez un jeton à IMDS en indiquant l’URI d’ID d’application comme valeur du paramètre resource. OpenAI utilise ce jeton comme jeton du sujet et l’échange contre un jeton d’accès qu’il émet.

APPLICATION_ID_URI="api://<application-client-id>"

TOKEN=$(curl -sS -G -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token" \
  --data-urlencode "api-version=2018-02-01" \
  --data-urlencode "resource=${APPLICATION_ID_URI}" \
  | jq -r .access_token)
export TOKEN

Si la ressource possède plusieurs identités managées attribuées par l’utilisateur, ajoutez le paramètre de requête client_id, object_id ou msi_res_id correspondant à l’identité souhaitée. Microsoft décrit les paramètres de demande de jeton IMDS dans le guide Utiliser des identités managées sur une machine virtuelle pour obtenir un jeton d’accès.

Vérification du jeton

Avant de configurer la fédération d’identités de charge de travail, exportez le jeton Microsoft Entra dans la variable TOKEN, puis exécutez ce script localement pour examiner ses revendications :

const parts = process.env.TOKEN?.split(".") ?? [];
if (parts.length !== 3) {
  throw new Error("Expected a compact JWT with three segments");
}
if (!/^[A-Za-z0-9_-]+$/.test(parts[1]) || parts[1].length % 4 === 1) {
  throw new Error("JWT payload is not valid Base64URL");
}

const bytes = Buffer.from(parts[1], "base64url");
if (bytes.toString("base64url") !== parts[1]) {
  throw new Error("JWT payload is not valid Base64URL");
}
const decoded = new TextDecoder("utf-8", { fatal: true }).decode(bytes);
const claims = JSON.parse(decoded);
if (claims === null || Array.isArray(claims) || typeof claims !== "object") {
  throw new Error("JWT payload is not a JSON object");
}
console.log(decoded);

Cette commande décode la charge utile du JWT sans vérifier la signature du jeton. Pour les jetons de production, utilisez un décodeur local et évitez de les coller dans des outils tiers.

Voici un exemple de jeton d’identité managée Microsoft Entra ID décodé :

{
  "iss": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0",
  "aud": "api://00000000-1111-2222-3333-444444444444",
  "tid": "11111111-2222-3333-4444-555555555555",
  "appid": "22222222-3333-4444-5555-666666666666",
  "oid": "33333333-4444-5555-6666-777777777777",
  "sub": "33333333-4444-5555-6666-777777777777",
  "xms_mirid": "/subscriptions/<subscription-id>/resourcegroups/my-resource-group/providers/Microsoft.Compute/virtualMachines/openai-wif-vm",
  "iat": 1716235422,
  "exp": 1716239022
}

Vérifiez les revendications que vous comptez utiliser dans votre configuration OpenAI :

  • iss : utilisez la valeur exacte de l’émetteur figurant dans le jeton. Il peut s’agir de https://login.microsoftonline.com/<tenant-id>/v2.0, mais ne présumez pas que le suffixe est toujours le même.
  • aud : la valeur doit correspondre à l’URI d’ID d’application, au paramètre resource d’IMDS et à l’audience du fournisseur d’identités de charge de travail configuré dans OpenAI.
  • tid : ID du locataire Microsoft Entra.
  • appid : ID d’application (ID client) de l’identité managée, si cette revendication est présente.
  • iat et exp : vérifiez la durée de vie totale du jeton, calculée en secondes avec exp - iat.

Pour Codex, définissez le paramètre max_assertion_lifetime_seconds du fournisseur sur une limite approuvée qui couvre toute la plage des durées de vie prévues pour les jetons de l’émetteur. N’utilisez pas la durée de validité restante du jeton et ne présumez pas que tous les jetons Entra sont valides une heure. Microsoft décrit les durées de vie variables des jetons d’accès et ne prend pas en charge la configuration de la durée de vie des jetons d’identité managée.

Les jetons d’identité managée peuvent aussi contenir des revendications telles que azp, oid, sub ou xms_mirid. Prenez le jeton décodé comme référence et choisissez des revendications qui identifient précisément l’identité managée et le périmètre de ressources auxquels vous faites confiance.

À partir de la charge utile décodée, comparez les valeurs du jeton reçu à celles de l’émetteur, de l’audience et du mappage configurés dans OpenAI. Avant même d’échanger le jeton, vous pouvez repérer la plupart des problèmes de configuration en examinant les revendications iss, aud, tid et celles propres à l’identité managée.

Configuration de la fédération d’identités de charge de travail

Dans OpenAI, créez un fournisseur d’identités de charge de travail pour l’émetteur Microsoft Entra ID, puis ajoutez un mappage de compte de service fondé sur des revendications stables du jeton d’identité managée.

Configurez d’abord le fournisseur d’identités de charge de travail, puis créez le mappage de compte de service.

Configuration du fournisseur d’identités de charge de travail

  1. Créez le fournisseur d’identités de charge de travail. Dans Nom, saisissez une valeur unique, par exemple azure-managed-identity-prod. Renseignez le champ Description, par exemple avec Production Azure managed identity workloads, pour aider les administrateurs à identifier le fournisseur.

  2. Définissez l’émetteur et l’audience. Dans URL de l’émetteur OIDC, saisissez la valeur exacte de la revendication iss du jeton. Pour la connaître, obtenez d’abord un jeton d’identité managée et examinez ses revendications. L’émetteur peut être, par exemple, https://login.microsoftonline.com/<tenant-id>/v2.0. Dans Audience, saisissez l’URI d’ID d’application Microsoft Entra que vous avez configuré, par exemple api://<application-client-id>. Cette valeur doit correspondre à la revendication aud du jeton.

  3. Utilisez la vérification des jetons Microsoft Entra. Laissez l’option Utiliser le JWKS importé pour vérifier les jetons désactivée. OpenAI utilise les métadonnées et le JWKS de l’émetteur Microsoft Entra pour vérifier le jeton d’identité managée.

  4. Ajoutez des transformations d’attributs si votre mappage nécessite des attributs dérivés. Par exemple, saisissez managed_identity_client_id et l’expression assertion.appid pour créer openai.managed_identity_client_id à partir de la revendication contenant l’ID d’application (ID client) de l’identité managée. Le tableau de bord ajoute automatiquement le préfixe openai.. OpenAI ignore les revendications brutes du jeton dont le nom commence déjà par openai. pour les clés de mappage préfixées par openai., sauf si vous configurez la transformation correspondante.

Configuration du mappage de compte de service

  1. Créez un mappage de compte de service. Dans Nom, saisissez une valeur unique pour ce fournisseur d’identités de charge de travail, par exemple vm-openai-wif. Renseignez le champ Description, par exemple avec Production VM Azure managed identity workload, pour indiquer quelle charge de travail peut utiliser ce mappage.

  2. Faites correspondre les revendications stables de l’identité managée. Pour chaque revendication à vérifier, ajoutez une ligne avec une Clé et une Valeur. Si le jeton contient appid, saisissez dans Clé la valeur appid et dans Valeur l’ID client de l’identité managée. La revendication appid contient l’ID d’application (ID client) de l’identité managée. C’est généralement la revendication la plus stable pour lier un mappage à une identité managée précise. Si votre jeton ne contient pas appid, utilisez une autre revendication stable du jeton décodé, par exemple azp, oid, sub ou xms_mirid. Pour limiter le mappage à un seul locataire, ajoutez une ligne avec Clé définie sur tid et Valeur définie sur l’ID du locataire Microsoft Entra. Décodez un jeton obtenu auprès d’IMDS et utilisez des revendications stables pour l’identité managée et la ressource auxquelles vous faites confiance.

  3. Choisissez la cible OpenAI. Dans Projet, sélectionnez le projet OpenAI auquel appartient le compte de service cible. Dans Compte de service, sélectionnez le compte de service OpenAI que la charge de travail Azure peut utiliser, par exemple azure-managed-identity-prod-openai-wif.

  4. Limitez les autorisations d’API si nécessaire. Sélectionnez les Autorisations appropriées, par exemple api.model.request et api.vector_store.read, pour restreindre davantage les droits conférés par les jetons d’accès émis à partir de ce mappage. Si vous laissez le champ vide, aucune restriction de portée propre à la fédération (WIF) ne s’ajoute. Les requêtes effectuées avec le jeton restent soumises aux autorisations du compte de service associé.

Utilisation du jeton dans le code

Configurez le client du SDK OpenAI pour qu’il demande un jeton d’identité managée Azure à IMDS et l’échange contre un jeton d’accès émis par OpenAI.

Définissez OPENAI_WIF_AUDIENCE sur l’URI d’ID d’application Microsoft Entra configuré comme audience du fournisseur d’identités de charge de travail. Le SDK demande un jeton d’identité managée pour cette audience, l’échange contre un jeton d’accès émis par OpenAI, puis utilise ce dernier pour authentifier les requêtes API.

Authentification à partir d’un jeton d’identité managée Azure
import OpenAI from "openai";

const imdsEndpoint = "http://169.254.169.254/metadata/identity/oauth2/token";

const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;
const audience = process.env.OPENAI_WIF_AUDIENCE;

if (!identityProviderId || !serviceAccountId || !audience) {
  throw new Error(
    "Set OPENAI_IDENTITY_PROVIDER_ID, OPENAI_SERVICE_ACCOUNT_ID, and OPENAI_WIF_AUDIENCE"
  );
}

function azureManagedIdentityTokenProvider(resource) {
  return {
    tokenType: "jwt",
    getToken: async () => {
      const url = new URL(imdsEndpoint);
      url.searchParams.set("api-version", "2018-02-01");
      url.searchParams.set("resource", resource);

      const clientId = process.env.AZURE_CLIENT_ID;
      if (clientId) {
        url.searchParams.set("client_id", clientId);
      }

      const response = await fetch(url, {
        headers: { Metadata: "true" },
      });

      if (!response.ok) {
        throw new Error(
          `Azure IMDS token request failed with status ${response.status}.`
        );
      }

      const body = await response.json();
      if (!body.access_token) {
        throw new Error("Azure IMDS did not return an access token.");
      }

      return body.access_token;
    },
  };
}

const client = new OpenAI({
  workloadIdentity: {
    identityProviderId,
    serviceAccountId,
    provider: azureManagedIdentityTokenProvider(audience),
  },
});

const response = await client.responses.create({
  model: "gpt-5.6-terra",
  input: "Say hello from Azure managed identity workload identity federation.",
});

console.log(response.output_text);

Bonnes pratiques pour Microsoft Azure

  • Utilisez des identités managées chaque fois que possible. Elles offrent un mode d’authentification plus simple et plus sûr que la distribution manuelle d’informations d’identification.
  • Utilisez des identités managées, des applications Microsoft Entra et des mappages OpenAI distincts pour chaque application et chaque environnement. Évitez de partager une identité entre les charges de travail de développement, de préproduction et de production.
  • Limitez les audiences acceptées. Configurez uniquement celles dont vous avez besoin pour la fédération d’identités de charge de travail OpenAI.
  • Utilisez une application Microsoft Entra ID dédiée à chaque périmètre de sécurité. Des applications distinctes permettent de mieux identifier les responsables et facilitent les audits et la gestion des accès.
  • Privilégiez les mappages propres à chaque charge de travail. Fondez les correspondances sur des revendications spécifiques à la charge de travail plutôt que sur des attributs communs à l’ensemble du locataire.
  • Vérifiez régulièrement la configuration des informations d’identification fédérées. Des informations d’identification obsolètes peuvent continuer à accorder un accès involontaire bien après la mise hors service des charges de travail.
  • Séparez les identités de production de celles des autres environnements. Les charges de travail de production doivent s’authentifier avec des identités fédérées et des comptes de service OpenAI distincts.