Utiliser WIF avec Microsoft Azure

Les charges de travail Azure s'authentifient auprès de l'API Claude en présentant un « JSON Web Token » (jeton web JSON), ou JWT, émis par Microsoft Entra ID, puis en l'échangeant contre un jeton d'accès Anthropic de courte durée. Il existe deux méthodes courantes pour obtenir le jeton émis par Entra :

• Identité managée (VM, App Service, Functions, Container Apps) : La charge de travail appelle l'Azure Instance Metadata Service (IMDS) à l'adresse http://169.254.169.254/metadata/identity/oauth2/token et reçoit un JWT pour l'identité qui lui est assignée.
• Entra Workload Identity (pods AKS) : Kubernetes projette un jeton de compte de service (signé par l'émetteur OIDC du cluster AKS) dans le pod au chemin indiqué dans AZURE_FEDERATED_TOKEN_FILE. La charge de travail échange ce jeton auprès d'Entra contre un jeton d'accès émis par Entra.

Dans les deux cas, le jeton émis par Entra que vous présentez à Anthropic contient un émetteur Entra spécifique au locataire (l'étape Configurer Anthropic ci-dessous indique l'URL exacte à enregistrer) et l'ID d'objet de l'identité managée dans les revendications sub et oid. Vous enregistrez cet émetteur auprès d'Anthropic une seule fois, rédigez une règle de fédération qui correspond aux revendications attendues, et votre charge de travail échange son jeton Entra contre un jeton d'accès sk-ant-oat01-... au moment de l'exécution.

Prérequis

• Une bonne connaissance des concepts WIF : comptes de service, émetteurs de fédération et règles de fédération.
• Un abonnement Azure avec l'autorisation d'assigner des identités managées (ou de configurer Entra Workload Identity sur AKS).
• Votre ID de locataire Microsoft Entra. Vous le trouverez dans le portail Azure sous Microsoft Entra ID → Overview → Tenant ID.
• L'autorisation de créer des comptes de service, des émetteurs de fédération et des règles de fédération dans la Claude Console pour votre organisation Anthropic.

Configurer Azure

Configurez l'identité pour laquelle Azure émettra des jetons. Choisissez l'approche qui correspond à l'environnement d'exécution de votre charge de travail.

Revendications du jeton

Un jeton émis par Entra pour une identité managée contient les revendications suivantes :

{
  "iss": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
  "sub": "9f8e7d6c-1a2b-3c4d-5e6f-...",
  "aud": "https://api.anthropic.com",
  "oid": "9f8e7d6c-1a2b-3c4d-5e6f-...",
  "tid": "<TENANT_ID>",
  "azp": "<CLIENT_ID>",
  "exp": 1775527120
}

sub et oid sont identiques (l'ID d'objet de l'identité managée). azp est l'ID d'application ou de client. Effectuez la correspondance sur oid pour autoriser une identité spécifique, ou sur azp pour autoriser toute identité associée à un enregistrement d'application. La revendication tid répète votre ID de locataire ; effectuer la correspondance sur celle-ci constitue une défense en profondeur, car l'URL de l'émetteur fixe déjà le locataire.

Configurer Anthropic

Suivez le guide de configuration pour enregistrer un émetteur de fédération, créer un compte de service Anthropic et créer une règle de fédération dans la Claude Console. Dans la Console, choisissez l'option de fournisseur OIDC et fournissez les valeurs spécifiques à Entra qui suivent.

Émetteur de fédération : Entra publie un document de découverte OIDC à l'URL d'émetteur propre à chaque locataire, utilisez donc le mode découverte. Chaque locataire Azure que vous fédérez nécessite son propre enregistrement d'émetteur.

{
  "name": "azure-prod-tenant",
  "issuer_url": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
  "jwks_source": "discovery"
}

Règle de fédération : Effectuez la correspondance sur l'ID d'objet de l'identité managée et sur votre ID de locataire.

{
  "name": "azure-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "https://api.anthropic.com",
    "claims": {
      "oid": "9f8e7d6c-1a2b-3c4d-5e6f-...",
      "tid": "<TENANT_ID>"
    }
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Acquérir et utiliser le jeton

Au moment de l'exécution, votre charge de travail récupère son jeton Entra, l'échange via POST /v1/oauth/token, et utilise le jeton porteur retourné pour appeler Claude. Chaque SDK Anthropic gère l'échange et la boucle de rafraîchissement lorsque vous fournissez un callable fournisseur de jeton, comme illustré dans les exemples suivants. L'onglet cURL montre le flux brut.

import os

import anthropic
import requests
from anthropic import WorkloadIdentityCredentials

IMDS_URL = "http://169.254.169.254/metadata/identity/oauth2/token"


def fetch_entra_token() -> str:
    """Fetch a managed identity token from Azure IMDS."""
    response = requests.get(
        IMDS_URL,
        headers={"Metadata": "true"},
        params={"api-version": "2018-02-01", "resource": "https://api.anthropic.com"},
        timeout=5,
    )
    response.raise_for_status()
    return response.json()["access_token"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_entra_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

Sur AKS avec Entra Workload Identity

Sur AKS, le fichier situé à AZURE_FEDERATED_TOKEN_FILE est un jeton de compte de service projeté par Kubernetes et signé par l'émetteur OIDC de votre cluster, et non un jeton émis par Entra. Pour rester sur le chemin médié par Entra décrit sur cette page, échangez d'abord ce jeton à l'adresse https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token (octroi client_credentials fédéré), puis transmettez le jeton d'accès Entra résultant au SDK Anthropic en tant que jeton d'identité.

import os
from pathlib import Path
import httpx
import anthropic
from anthropic import WorkloadIdentityCredentials


def fetch_entra_token_via_federation() -> str:
    federated_token = Path(os.environ["AZURE_FEDERATED_TOKEN_FILE"]).read_text()
    response = httpx.post(
        f"https://login.microsoftonline.com/{os.environ['AZURE_TENANT_ID']}/oauth2/v2.0/token",
        data={
            "client_id": os.environ["AZURE_CLIENT_ID"],
            "grant_type": "client_credentials",
            "scope": "https://api.anthropic.com/.default",
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            "client_assertion": federated_token,
        },
    )
    response.raise_for_status()
    return response.json()["access_token"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_entra_token_via_federation,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

Vous pouvez également enregistrer directement l'émetteur OIDC de votre cluster AKS auprès d'Anthropic et ignorer l'étape Entra. Consultez Kubernetes pour ce modèle.

Vérifier la configuration

Depuis votre ressource Azure, exécutez l'échange cURL présenté précédemment et confirmez que POST /v1/oauth/token retourne un code 200 avec un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. En cas de 400 invalid_grant, consultez Résoudre un échec d'échange ; la cause la plus courante côté Azure est une incohérence entre l'issuer_url que vous avez enregistrée et la revendication iss de votre jeton décodé. Elles doivent correspondre exactement. Pour les jetons d'identité managée, la valeur iss est soit https://login.microsoftonline.com/<TENANT_ID>/v2.0, soit https://sts.windows.net/<TENANT_ID>/.

Délimiter votre règle

Restreignez le bloc match de la règle à la portée la plus étroite qui convient à votre cas d'usage :

• Faites correspondre oid comme valeur exacte : Définissez claims.oid sur l'ID d'objet complet de l'identité managée et n'utilisez jamais subject_prefix pour les jetons Azure.
• Fixez tid comme défense en profondeur : L'URL de l'émetteur fixe déjà votre locataire, mais l'ajout de claims.tid protège contre une dérive de configuration si l'enregistrement de l'émetteur est modifié ultérieurement.
• Fixez l'audience : Définissez audience sur https://api.anthropic.com afin que les jetons émis pour d'autres ressources soient rejetés.
• Utilisez une règle distincte par identité managée : Créez une règle par identité plutôt qu'une seule règle qui en autorise plusieurs, afin de pouvoir révoquer l'accès d'une seule charge de travail sans affecter les autres.

Étapes suivantes

• Consultez le modèle de configuration complet dans Workload Identity Federation.
• Consultez les guides des fournisseurs pour AWS, Google Cloud, GitHub Actions et Kubernetes.
• Pour les variables d'environnement, les fichiers de profil et la priorité des informations d'identification, consultez la référence WIF.