Claude Platform Docs
AdministrationFournisseurs d'identité

Utiliser WIF avec Microsoft Entra ID

Fédérez les identités managées Azure et Entra Workload Identity avec la Claude API afin que vos charges de travail Azure puissent appeler Claude sans clés API statiques.

Les charges de travail Azure s'authentifient auprès de la Claude API 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. La configuration suit le même schéma sur chaque plateforme Azure :

  1. Enregistrer l'audience du jeton : créez une « app registration » (inscription d'application) dans votre « tenant » (locataire) Microsoft Entra pour représenter l'audience de la Claude API. Chaque charge de travail du locataire demande des jetons Entra pour celle-ci.
  2. Configurer l'identité pour votre plateforme : une « managed identity » (identité managée) sur les machines virtuelles, les VM Scale Sets, App Service, Functions et Container Apps, ou Entra Workload Identity sur AKS.
  3. Configurer Anthropic : enregistrez l'émetteur Entra de votre locataire, créez un compte de service et rédigez une règle de fédération qui correspond aux « claims » (revendications) du jeton.
  4. Échanger à l'exécution : votre charge de travail échange son jeton émis par Entra via POST /v1/oauth/token contre un jeton d'accès Anthropic sk-ant-oat01-... et appelle Claude avec celui-ci.

Dans les deux parcours, le jeton que vous présentez à Anthropic contient l'émetteur Entra propre à votre locataire et l'ID d'objet de l'identité managée dans les revendications sub et oid ; seule la manière dont la charge de travail obtient ce jeton diffère. Choisissez la section correspondant à l'endroit où s'exécute votre charge de travail : Utiliser une identité managée pour les machines virtuelles, les VM Scale Sets, App Service, Functions ou Container Apps ; Utiliser Entra Workload Identity sur AKS pour AKS.

Prérequis

  • Une familiarité avec les concepts WIF : comptes de service, émetteurs de fédération et règles de fédération.
  • Un abonnement Azure avec l'autorisation d'attribuer des identités managées (ou de configurer Entra Workload Identity sur AKS).
  • L'autorisation de créer une inscription d'application et un « service principal » (principal de service) dans votre locataire Microsoft Entra (l'audience partagée de la Claude API). Entra n'émet des jetons que pour une audience qui existe dans le locataire ; l'étape Enregistrer l'audience du jeton est donc requise avant qu'une demande de jeton puisse aboutir.
  • L'ID de votre 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.

Enregistrer l'audience du jeton

Microsoft Entra ID n'émet un jeton que lorsque l'audience demandée existe dans votre locataire sous la forme d'une inscription d'application dotée d'un principal de service. Créez une inscription d'application pour représenter l'audience de la Claude API ; chaque charge de travail du locataire peut demander des jetons pour celle-ci. Sans cette inscription, les demandes de jeton échouent avec une erreur « resource not found in tenant » (AADSTS50001 depuis les points de terminaison d'identité managée, AADSTS500011 depuis le point de terminaison de jeton Entra).

# Créez l'inscription d'application qui représente l'audience de la Claude API.
APP_ID=$(az ad app create --display-name claude-api-federation --query appId -o tsv)

# Demandez des jetons d'accès v2.0 et définissez l'URI d'identifiant api://<APP_ID>.
az ad app update --id "$APP_ID" \
  --identifier-uris "api://$APP_ID" \
  --set api.requestedAccessTokenVersion=2

# Créez le principal de service afin que l'audience soit résolue dans votre locataire.
az ad sp create --id "$APP_ID"

Utiliser une identité managée

Utilisez ce parcours lorsque votre charge de travail s'exécute sur une machine virtuelle, un VM Scale Set, App Service, Functions ou Container Apps. La charge de travail demande un JWT émis par Entra pour l'identité managée qui lui est attribuée auprès du point de terminaison de jeton local de la plateforme, puis échange ce JWT avec Anthropic.

Configurer l'identité managée

  1. Attacher une identité managée

    Activez une identité managée affectée par le système ou affectée par l'utilisateur sur votre ressource Azure. Dans le portail Azure, ouvrez la ressource, accédez à Identity et activez System assigned (ou attachez une identité affectée par l'utilisateur).

    Une fois l'identité créée, notez son Object (principal) ID. Ce GUID apparaît à la fois dans les revendications sub et oid du jeton émis, et votre règle de fédération Anthropic effectuera la correspondance sur celui-ci. Vous le trouverez sur la page Identity de la ressource ; pour une identité affectée par l'utilisateur, il s'agit de l'Object (principal) ID sur la page Overview de la ressource d'identité managée. (Une identité managée ne possède qu'un principal de service dans Microsoft Entra ID, pas d'inscription d'application.)

  2. Trouver le point de terminaison de jeton de la plateforme

    La plateforme expose un point de terminaison de jeton local une fois l'identité attachée :

    • Machines virtuelles et VM Scale Sets : IMDS à l'adresse http://169.254.169.254/metadata/identity/oauth2/token avec l'en-tête Metadata: true et api-version=2018-02-01.
    • App Service, Functions et Container Apps : l'URL contenue dans la variable d'environnement IDENTITY_ENDPOINT avec l'en-tête X-IDENTITY-HEADER défini sur la valeur de IDENTITY_HEADER, et api-version=2019-08-01. IMDS n'est pas accessible sur ces plateformes.

    Si la ressource possède plus d'une identité managée affectée par l'utilisateur, ajoutez client_id=<IDENTITY_CLIENT_ID> à la demande de jeton pour en sélectionner une. Azure recommande de toujours le spécifier. Sans cela, le résultat dépend de la présence ou non d'une identité affectée par le système également activée sur la ressource : si c'est le cas, la demande bascule silencieusement sur cette identité puis échoue à la correspondance oid de votre règle de fédération ; si ce n'est pas le cas, la demande échoue purement et simplement dès qu'une deuxième identité affectée par l'utilisateur est attachée.

  3. Décoder un exemple de jeton

    Demandez un jeton au point de terminaison et décodez sa charge utile pour confirmer les revendications sur lesquelles votre règle de fédération doit effectuer la correspondance. (Pour la commande de décodage, consultez Dépanner un échange en échec.) Un jeton v2.0 pour une identité managée contient ces revendications :

    {
  "iss": "https://login.microsoftonline.com/<TENANT_ID>/v2.0",
  "sub": "9f8e7d6c-1a2b-3c4d-5e6f-...",
  "aud": "<APP_ID>",
  "oid": "9f8e7d6c-1a2b-3c4d-5e6f-...",
  "tid": "<TENANT_ID>",
  "azp": "<IDENTITY_CLIENT_ID>",
  "ver": "2.0",
  "exp": 1775527120
}
    RevendicationValeurEffectuez la correspondance sur celle-ci lorsque
    oidL'ID d'objet de l'identité managée, identique à subVous souhaitez autoriser une identité managée spécifique. C'est le comportement par défaut ; la règle de Configurer Anthropic effectue la correspondance sur celle-ci.
    azpL'ID client de l'identité appelanteVous souhaitez autoriser toutes les charges de travail qui partagent une même inscription d'application. Pour une identité managée, azp est propre à cette identité, il est donc équivalent à oid.
    audL'ID client de l'inscription d'application d'audience (le GUID <APP_ID> de Enregistrer l'audience du jeton)Toujours. Le champ audience de la règle doit être exactement égal à la valeur aud du jeton.
    tidL'ID de votre locataireVous souhaitez une défense en profondeur. L'URL de l'émetteur fixe déjà le locataire.

    Si la revendication ver du jeton décodé vaut 1.0, les noms et valeurs des revendications diffèrent. Consultez Si vos jetons sont en v1.0 avant de continuer.

Configurer Anthropic

Dans la Claude Console, ouvrez Settings → Workload identity, cliquez sur Connect workload et sélectionnez la tuile Microsoft Entra. L'assistant vous guide dans l'enregistrement de l'émetteur, la création d'un compte de service et la création d'une règle de fédération.

L'assistant crée ces ressources pour vous. Utilisez les valeurs suivantes, que vous les saisissiez dans l'assistant ou que vous les envoyiez à l'Admin API :

Émetteur de fédération : choisissez v2.0 (login.microsoftonline.com) dans le sélecteur Token issuer de l'assistant. (Le sélecteur est défini par défaut sur v1 ; cette valeur par défaut existe pour les locataires qui réutilisent d'anciennes inscriptions émettant encore des jetons v1.0.) Entra publie un document de découverte OIDC à l'URL d'émetteur propre au locataire ; utilisez donc le mode découverte. Chaque locataire Microsoft Entra 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": { "type": "discovery" },
  "max_jwt_lifetime_seconds": 86400
}

Une durée de vie acceptée plus longue signifie qu'un jeton Entra divulgué reste échangeable plus longtemps. Si un jeton est divulgué, le levier consiste à désactiver la règle de fédération ; une correspondance stricte sur oid limite en premier lieu les identités pouvant échanger un jeton, comme décrit dans Délimiter votre règle.

Règle de fédération : effectuez la correspondance sur l'ID d'objet de l'identité managée et l'ID de votre locataire. Pour les jetons v2.0 que ce guide configure, la valeur audience est l'ID client de l'inscription d'application d'audience (le GUID <APP_ID> de Enregistrer l'audience du jeton). Utilisez la valeur aud exacte de votre jeton décodé.

{
  "name": "azure-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "<APP_ID>",
    "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
}

token_lifetime_seconds est la durée de vie du jeton d'accès Anthropic renvoyé par l'échange, et non celle du jeton Entra ; le SDK le renouvelle pour vous.

Acquérir et utiliser le jeton

À 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 renvoyé pour appeler Claude. Chaque SDK Anthropic gère l'échange et la boucle de renouvellement lorsque vous fournissez un callable fournisseur de jeton, comme le montrent les exemples suivants. L'onglet cURL montre le flux brut.

Les exemples récupèrent le jeton d'identité managée auprès du point de terminaison de jeton de la plateforme : IMDS sur les machines virtuelles et les VM Scale Sets, ou le service IDENTITY_ENDPOINT sur App Service, Functions et Container Apps. Remplacez <APP_ID> dans la valeur de ressource api://<APP_ID> par l'ID client de l'inscription d'application d'audience de Enregistrer l'audience du jeton.

import os

import anthropic
import requests
from anthropic import WorkloadIdentityCredentials

# L'URI d'identifiant de l'inscription d'application d'audience (voir Enregistrer l'audience du jeton).
AUDIENCE = "api://<APP_ID>"


def fetch_entra_token() -> str:
    """Fetch a managed identity token from the platform's token endpoint."""
    # Avec plusieurs identités attribuées par l'utilisateur, ajoutez client_id=<IDENTITY_CLIENT_ID>
    # aux paramètres de la requête pour en sélectionner une.
    if endpoint := os.environ.get("IDENTITY_ENDPOINT"):
        # App Service, Functions, Container Apps
        response = requests.get(
            endpoint,
            headers={"X-IDENTITY-HEADER": os.environ["IDENTITY_HEADER"]},
            params={"api-version": "2019-08-01", "resource": AUDIENCE},
            timeout=5,
        )
    else:
        # VM ou VM Scale Set : Azure Instance Metadata Service (IMDS)
        response = requests.get(
            "http://169.254.169.254/metadata/identity/oauth2/token",
            headers={"Metadata": "true"},
            params={"api-version": "2018-02-01", "resource": AUDIENCE},
            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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(next(block.text for block in message.content if block.type == "text"))

Vérifier la configuration

Depuis votre ressource Azure, exécutez l'échange cURL présenté dans Acquérir et utiliser le jeton et confirmez que POST /v1/oauth/token renvoie un 200 avec un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. Si l'échange échoue avec la réponse opaque 401 authentication_error (message Authentication failed), consultez la page d'historique d'authentification pour connaître le motif du refus, puis décodez le jeton Entra (consultez Dépanner un échange en échec pour la commande) et vérifiez les causes les plus courantes côté Azure :

  • Non-concordance de l'émetteur : l'issuer_url enregistrée doit correspondre exactement à la revendication iss du jeton. Un jeton v2.0 contient https://login.microsoftonline.com/<TENANT_ID>/v2.0 ; si la revendication ver décodée vaut 1.0, consultez Si vos jetons sont en v1.0.
  • Durée de vie du jeton : les jetons d'identité managée comportent jusqu'à 24 heures entre iat et exp. Si l'émetteur a toujours la valeur 7500 de l'assistant (ou la valeur par défaut d'une heure), augmentez max_jwt_lifetime_seconds à 86400 comme décrit dans Configurer Anthropic.
  • Non-concordance de l'audience : l'audience de la règle doit être exactement égale à l'aud du jeton : l'ID client de l'inscription d'application d'audience pour les jetons v2.0 que ce guide configure.
  • Non-concordance du nom de revendication : une règle qui effectue la correspondance sur une revendication absente du jeton ne passe jamais. Les jetons v1.0 contiennent l'ID client dans appid, et non dans azp ; consultez Si vos jetons sont en v1.0.

Utiliser Entra Workload Identity sur AKS

Utilisez ce parcours lorsque votre charge de travail s'exécute dans un pod AKS. Entra Workload Identity fédère un compte de service Kubernetes avec une identité managée affectée par l'utilisateur : 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. Ce jeton projeté n'est pas un jeton émis par Entra ; pour rester sur le parcours passant par Entra décrit sur cette page, la charge de travail effectue donc un échange en deux étapes : elle échange d'abord le jeton projeté auprès de https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token (octroi client_credentials fédéré) contre un jeton d'accès émis par Entra, puis transmet ce jeton Entra au SDK Anthropic comme jeton d'identité.

Configurer Entra Workload Identity

  1. Activer l'émetteur OIDC et l'identité de charge de travail sur votre cluster

    L'activation de l'identité de charge de travail installe pour vous le webhook de mutation azure-workload-identity ; ne le déployez manuellement que sur les clusters non AKS. Récupérez l'URL de l'émetteur OIDC du cluster pour les informations d'identification fédérées que vous créerez à une étape ultérieure.

    az aks update \
  --resource-group <RESOURCE_GROUP> \
  --name <CLUSTER_NAME> \
  --enable-oidc-issuer \
  --enable-workload-identity

AKS_OIDC_ISSUER=$(az aks show \
  --resource-group <RESOURCE_GROUP> \
  --name <CLUSTER_NAME> \
  --query oidcIssuerProfile.issuerUrl -o tsv)

  2. Créer une identité managée affectée par l'utilisateur

    Récupérez deux valeurs de l'identité : le Client ID va dans l'annotation du compte de service (et est injecté dans le pod sous la forme AZURE_CLIENT_ID), et l'Object (principal) ID apparaît dans la revendication oid sur laquelle votre règle de fédération Anthropic effectue la correspondance.

    az identity create \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --location <LOCATION>

# À placer dans l'annotation du compte de service ; injecté dans le pod sous le nom AZURE_CLIENT_ID.
IDENTITY_CLIENT_ID=$(az identity show \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --query clientId -o tsv)

# Apparaît comme la revendication oid à laquelle votre règle de fédération correspond.
IDENTITY_OBJECT_ID=$(az identity show \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --query principalId -o tsv)

  3. Créer le compte de service Kubernetes annoté

    Le webhook azure-workload-identity lit l'annotation azure.workload.identity/client-id pour injecter AZURE_CLIENT_ID dans le pod, que les exemples de Acquérir et utiliser le jeton lisent depuis l'environnement.

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: claude-inference
  namespace: inference
  annotations:
    azure.workload.identity/client-id: <IDENTITY_CLIENT_ID>

  4. Créer les informations d'identification fédérées sur l'identité managée

    Les informations d'identification fédérées font confiance à l'émetteur OIDC de votre cluster pour ce compte de service spécifique. La valeur --audience api://AzureADTokenExchange est l'audience fixe d'Entra pour les jetons de compte de service Kubernetes entrants ; elle n'a aucun lien avec l'audience de la Claude API que vous avez enregistrée précédemment.

    az identity federated-credential create \
  --resource-group <RESOURCE_GROUP> \
  --identity-name claude-inference-identity \
  --name claude-inference-aks \
  --issuer "$AKS_OIDC_ISSUER" \
  --subject system:serviceaccount:inference:claude-inference \
  --audience api://AzureADTokenExchange

  5. Étiqueter le pod et définir son compte de service

    Le pod doit porter l'étiquette azure.workload.identity/use: "true" et s'exécuter en tant que compte de service annoté. Le webhook injecte alors AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID et AZURE_TENANT_ID dans le pod. Le fichier situé à AZURE_FEDERATED_TOKEN_FILE contient le jeton de compte de service projeté par Kubernetes, signé par l'émetteur OIDC du cluster AKS.

    apiVersion: v1
kind: Pod
metadata:
  name: inference-worker
  namespace: inference
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: claude-inference
  containers:
    - name: app
      image: your-registry/inference-worker:latest

  6. Décoder un exemple de jeton

    Le jeton que voit votre règle de fédération Anthropic n'est pas le fichier projeté ; il s'agit du jeton émis par Entra renvoyé par l'échange client_credentials. Depuis l'intérieur d'un pod étiqueté, exécutez l'étape 1 de l'exemple cURL de Acquérir et utiliser le jeton et décodez le résultat. Il présente la même structure de revendications que le parcours par identité managée :

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

    sub et oid sont l'ID d'objet de l'identité managée, aud est l'ID client de l'inscription d'application d'audience, et azp est l'ID client de l'identité managée (la valeur de AZURE_CLIENT_ID). La durée de vie diffère du parcours par identité managée : les jetons client_credentials ont par défaut une fenêtre aléatoire de 60 à 90 minutes entre iat et exp, et non 24 heures.

Configurer Anthropic

Dans la Claude Console, ouvrez Settings → Workload identity, cliquez sur Connect workload et sélectionnez la tuile Microsoft Entra. L'assistant vous guide dans l'enregistrement de l'émetteur, la création d'un compte de service et la création d'une règle de fédération.

L'assistant crée ces ressources pour vous. Utilisez les valeurs suivantes, que vous les saisissiez dans l'assistant ou que vous les envoyiez à l'Admin API :

Émetteur de fédération : choisissez v2.0 (login.microsoftonline.com) dans le sélecteur Token issuer de l'assistant. (Le sélecteur est défini par défaut sur v1 ; cette valeur par défaut existe pour les locataires qui réutilisent d'anciennes inscriptions émettant encore des jetons v1.0.) Entra publie un document de découverte OIDC à l'URL d'émetteur propre au locataire ; utilisez donc le mode découverte. Chaque locataire Microsoft Entra 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": { "type": "discovery" },
  "max_jwt_lifetime_seconds": 7500
}

Une durée de vie acceptée plus longue signifie qu'un jeton Entra divulgué reste échangeable plus longtemps. Si un jeton est divulgué, le levier consiste à désactiver la règle de fédération ; une correspondance stricte sur oid limite en premier lieu les identités pouvant échanger un jeton, comme décrit dans Délimiter votre règle.

Règle de fédération : effectuez la correspondance sur l'ID d'objet de l'identité managée et l'ID de votre locataire. Pour les jetons v2.0 que ce guide configure, la valeur audience est l'ID client de l'inscription d'application d'audience (le GUID <APP_ID> de Enregistrer l'audience du jeton). Utilisez la valeur aud exacte de votre jeton décodé.

{
  "name": "azure-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "<APP_ID>",
    "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
}

token_lifetime_seconds est la durée de vie du jeton d'accès Anthropic renvoyé par l'échange, et non celle du jeton Entra ; le SDK le renouvelle pour vous.

Acquérir et utiliser le jeton

À l'exécution, le pod effectue l'échange en deux étapes : il envoie le jeton projeté par Kubernetes (le fichier situé à AZURE_FEDERATED_TOKEN_FILE) au point de terminaison de jeton d'Entra en tant qu'assertion client_credentials fédérée, puis échange le jeton d'accès Entra obtenu via POST /v1/oauth/token. Chaque SDK Anthropic gère le second échange et la boucle de renouvellement lorsque vous fournissez la récupération Entra sous forme de callable fournisseur de jeton, comme le montrent les exemples suivants. L'onglet cURL montre le flux brut.

Deux ID client différents apparaissent dans les exemples. <APP_ID> est l'ID client de l'inscription d'application d'audience de Enregistrer l'audience du jeton ; la portée api://<APP_ID>/.default demande à Entra un jeton adressé à cette audience. $AZURE_CLIENT_ID est l'ID client de l'identité managée, injecté par le webhook, et identifie l'appelant. Ne substituez pas l'un à l'autre.

import os
from pathlib import Path

import anthropic
import requests
from anthropic import WorkloadIdentityCredentials


def fetch_entra_token_via_federation() -> str:
    federated_token = Path(os.environ["AZURE_FEDERATED_TOKEN_FILE"]).read_text()
    response = requests.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": "api://<APP_ID>/.default",
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            "client_assertion": federated_token,
        },
        timeout=5,
    )
    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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(next(block.text for block in message.content if block.type == "text"))

Vérifier la configuration

Depuis l'intérieur d'un pod étiqueté, exécutez l'échange cURL présenté dans Acquérir et utiliser le jeton et confirmez que POST /v1/oauth/token renvoie un 200 avec un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. Si l'échange échoue avec la réponse opaque 401 authentication_error (message Authentication failed), consultez la page d'historique d'authentification pour connaître le motif du refus, puis décodez le jeton émis par Entra de l'étape 1 (consultez Dépanner un échange en échec pour la commande) et vérifiez les causes les plus courantes côté Azure :

  • Non-concordance de l'émetteur : l'issuer_url enregistrée doit correspondre exactement à la revendication iss du jeton. Un jeton v2.0 contient https://login.microsoftonline.com/<TENANT_ID>/v2.0 ; si la revendication ver décodée vaut 1.0, consultez Si vos jetons sont en v1.0.
  • Durée de vie du jeton : si une stratégie de durée de vie des jetons du locataire ou la CAE prolonge le jeton client_credentials au-delà de 7500 secondes, augmentez le max_jwt_lifetime_seconds de l'émetteur comme décrit dans Configurer Anthropic.
  • Non-concordance de l'audience : l'audience de la règle doit être exactement égale à l'aud du jeton : l'ID client de l'inscription d'application d'audience pour les jetons v2.0 que ce guide configure.
  • Non-concordance du nom de revendication : une règle qui effectue la correspondance sur une revendication absente du jeton ne passe jamais. Les jetons v1.0 contiennent l'ID client dans appid, et non dans azp ; consultez Si vos jetons sont en v1.0.

Si vos jetons sont en v1.0

Ce guide configure l'inscription d'application d'audience avec api.requestedAccessTokenVersion: 2, de sorte que chaque jeton qu'il présente est en v2.0. Si vous réutilisez une inscription existante qui laisse requestedAccessTokenVersion non défini, Entra émet des jetons v1.0 à la place. Décodez un exemple de jeton et vérifiez sa revendication ver ; si elle vaut 1.0, quatre éléments changent :

  • Émetteur : la revendication iss est https://sts.windows.net/<TENANT_ID>/ au lieu de https://login.microsoftonline.com/<TENANT_ID>/v2.0. Enregistrez l'URL de l'émetteur exactement telle qu'elle figure dans la revendication iss de votre jeton. Les deux URL partagent le même JWKS, le mode découverte fonctionne donc pour l'une comme pour l'autre.
  • Sélecteur de l'assistant : choisissez v1 (sts.windows.net) dans le sélecteur Token issuer de l'assistant Connect workload au lieu de v2.0 (login.microsoftonline.com).
  • Audience : la revendication aud est l'URI d'identifiant que vous avez transmise comme resource (par exemple, api://<APP_ID>), et non l'ID client de l'inscription. Définissez l'audience de la règle de fédération sur la valeur aud exacte de votre jeton décodé.
  • Revendication d'ID client : l'ID client de l'identité appelante apparaît dans appid, et non dans azp. Les deux revendications n'apparaissent jamais dans le même jeton ; une règle qui effectue la correspondance sur azp ne passe donc jamais avec un jeton v1.0.

Les revendications oid, sub et tid contiennent les mêmes valeurs dans les deux versions, le reste de ce guide s'applique donc sans modification.

Délimiter votre règle

Une règle de fédération peut effectuer la correspondance sur le sujet du jeton avec subject_prefix en plus (ou à la place) de la table claims ; consultez Sémantique de correspondance des règles pour savoir comment les champs se combinent. Les valeurs sub d'Entra pour ces identités sont des GUID canoniques de longueur fixe ; un subject_prefix contenant l'ID d'objet complet de 36 caractères ne correspond donc qu'à ce sujet. Il s'agit d'une propriété du format de sujet d'Entra, et non de subject_prefix en général.

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

  • Faire correspondre oid comme valeur exacte : définissez claims.oid sur l'ID d'objet complet de l'identité managée. Un subject_prefix défini sur cet ID d'objet complet est équivalent (l'assistant de la Console définit les deux) ; n'utilisez jamais un subject_prefix générique ou à GUID partiel, qui correspond à plus d'identités que vous ne le souhaitez.
  • Fixer 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.
  • Fixer l'audience : définissez audience sur la valeur aud exacte de votre jeton décodé afin que les jetons émis pour d'autres applications soient rejetés.
  • Utiliser une règle distincte pour chaque identité managée : créez une règle pour chaque 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

Was this page helpful?