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

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

Utilisez Microsoft Azure comme fournisseur d’identités de charge de travail dans l’un des scénarios suivants :

  • 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 token projeté de compte de service Azure Kubernetes Service (AKS) contre un jeton d’accès OpenAI de courte durée.

Pour Codex, suivez les instructions de cette page pour obtenir et examiner le token Microsoft Entra. Ensuite, configurez l’identité de charge de travail de Codex pour écrire ce token dans un fichier et indiquer son emplacement à Codex. Le mappage de compte de service et les exemples de SDK de cette page s’appliquent à l’API OpenAI.

Identité managée Azure

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

Configuration d’une identité managée Azure

Créez ou utilisez une inscription d’application Microsoft Entra qui représente l’audience des tokens à laquelle OpenAI doit faire confiance. Configurez son URI d’ID d’application ; cet URI est la valeur resource que votre charge de travail demande à Azure Instance Metadata Service (IMDS), et il apparaît dans la revendication aud du token émis. Pour connaître les étapes de configuration côté Microsoft, consultez le guide Microsoft Entra expliquant comment 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 token obtenu et l’audience du fournisseur d’identités de charge de travail OpenAI doivent tous correspondre.

Créez une identité managée, puis attribuez cette identité managée à la ressource Azure qui exécute votre application, par exemple une machine virtuelle. La ressource doit pouvoir appeler IMDS lors de l’exécution. Pour en savoir plus sur la configuration Azure, consultez la présentation des identités managées de Microsoft ainsi que la documentation de la ressource Azure concernée pour l’attribution de l’identité.

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

Depuis la ressource Azure à laquelle l’identité managée est attribuée, demandez un token à IMDS en utilisant l’URI d’ID d’application comme paramètre resource. Ce token est le token de sujet qu’OpenAI échange contre un jeton d’accès émis par OpenAI.

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 dispose 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é managée que vous souhaitez utiliser. Microsoft décrit les paramètres de demande de token IMDS dans Utiliser des identités managées sur une machine virtuelle pour obtenir un jeton d’accès.

Vérifiez le token

Avant de configurer la fédération d’identités de charge de travail, exportez le token 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 token. Utilisez un décodeur local pour les tokens de production et évitez de les coller dans des outils tiers.

Une fois décodé, un token d’identité managée Microsoft Entra ID ressemble à ceci :

{
  "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 prévoyez de configurer dans OpenAI :

  • iss : utilisez la valeur exacte de l’émetteur figurant dans le token. L’émetteur peut être https://login.microsoftonline.com/<tenant-id>/v2.0, mais ne présumez pas de la présence de ce suffixe.
  • aud : 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 OpenAI.
  • tid : ID du locataire Microsoft Entra.
  • appid : ID d’application/client de l’identité managée, lorsque cette revendication est présente.
  • iat et exp : vérifiez la durée de vie totale du token, exp - iat, en secondes.

Pour Codex, définissez le paramètre max_assertion_lifetime_seconds du fournisseur sur une limite approuvée qui couvre la plage de durées de vie des tokens attendue pour l’émetteur. N’utilisez pas la durée de validité restante du token et ne supposez pas que tous les tokens Entra durent une heure. Microsoft documente 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 tokens d’identité managée. Consultez l’exemple de fournisseur avec l’API d’administration.

Les tokens d’identité managée peuvent également contenir des revendications telles que azp, oid, sub ou xms_mirid. Prenez le token 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.

Utilisez la charge utile décodée pour comparer le token reçu aux valeurs d’émetteur, d’audience et de mappage configurées dans OpenAI. La plupart des problèmes de configuration sont visibles dans les revendications iss, aud, tid et celles de l’identité managée avant l’échange du token.

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

Créez un fournisseur d’identités de charge de travail dans OpenAI pour l’émetteur Microsoft Entra ID, puis ajoutez un mappage de compte de service qui correspond à des revendications stables du token 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.

Configurez le fournisseur d’identités de charge de travail

  1. Créez le fournisseur d’identités de charge de travail. Définissez le champ Nom sur une valeur unique, telle que 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. Définissez le champ URL de l’émetteur OIDC sur la valeur exacte de la revendication iss du token. Commencez par obtenir un exemple de token d’identité managée et examinez ses revendications. Par exemple, l’émetteur peut être https://login.microsoftonline.com/<tenant-id>/v2.0. Définissez le champ Audience sur l’URI d’ID d’application Microsoft Entra que vous avez configuré, tel que api://<application-client-id>. Cette valeur doit correspondre à la revendication aud du token.

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

  4. Ajoutez des transformations d’attributs si vous avez besoin d’attributs dérivés pour le mappage. Par exemple, saisissez managed_identity_client_id avec l’expression assertion.appid pour créer openai.managed_identity_client_id à partir de la revendication d’ID d’application/client de l’identité managée. Le tableau de bord applique automatiquement le préfixe openai.. Les revendications brutes du token qui commencent déjà par openai. sont ignorées pour les clés de mappage openai., sauf si une transformation correspondante est configurée.

Configurez le mappage de compte de service

  1. Créez un mappage de compte de service. Définissez le champ Nom sur une valeur unique au sein de ce fournisseur d’identités de charge de travail, telle que vm-openai-wif. Renseignez le champ Description, par exemple avec Production VM Azure managed identity workload, pour préciser quelle charge de travail peut utiliser ce mappage.

  2. Faites correspondre des revendications stables de l’identité managée. Ajoutez une ligne Clé et Valeur pour chaque revendication devant correspondre. Si le token contient appid, définissez Clé sur appid et Valeur sur l’ID client de l’identité managée. La revendication appid identifie l’ID d’application/client de l’identité managée et constitue généralement la revendication la plus stable pour lier un mappage à une identité managée précise. Si votre token ne contient pas appid, utilisez une autre revendication stable du token décodé, telle que azp, oid, sub ou xms_mirid. Pour lier le mappage à un seul locataire, définissez également Clé sur tid et Valeur sur l’ID du locataire Microsoft Entra. Décodez un exemple de token 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. Définissez Projet sur le projet OpenAI auquel appartient le compte de service cible. Définissez Compte de service sur le compte de service OpenAI que la charge de travail Azure peut utiliser, tel que azure-managed-identity-prod-openai-wif.

  4. Restreignez les autorisations de l’API si nécessaire. Sélectionnez les Autorisations appropriées, telles que api.model.request et api.vector_store.read, pour restreindre davantage les jetons d’accès émis à partir de ce mappage. Laissez les autorisations vides pour ne pas ajouter de restriction de portée propre à WIF ; le token continue d’autoriser l’accès au nom du compte de service associé.

Utilisation du token dans le code

Configurez votre client SDK OpenAI pour demander un token d’identité managée Azure à IMDS et l’échanger 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 token d’identité managée pour cette audience, l’échange contre un jeton d’accès émis par OpenAI et utilise ce token OpenAI pour authentifier les requêtes à l’API.

Authentifiez-vous à l’aide d’un token 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 modèle 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 les différentes applications et les différents environnements. Évitez de partager une même identité entre les charges de travail de développement, de préproduction et de production.
  • Limitez les audiences acceptées. Configurez uniquement les audiences nécessaires à la fédération d’identités de charge de travail OpenAI.
  • Utilisez des applications Microsoft Entra ID dédiées pour délimiter les périmètres de sécurité. Des applications distinctes permettent de clarifier les responsabilités, les audits et la gestion des accès.
  • Privilégiez les mappages propres à chaque charge de travail. Établissez les correspondances à partir de revendications propres à la charge de travail plutôt que d’attributs généraux communs à tout le locataire.
  • Vérifiez régulièrement la configuration des informations d’identification fédérées. Des informations d’identification fédérées obsolètes peuvent continuer à accorder involontairement un accès longtemps 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.