Usar WIF con Microsoft Azure

Las cargas de trabajo de Azure se autentican ante la API de Claude presentando un "JSON Web Token" (token web JSON), o JWT, emitido por Microsoft Entra ID, y luego intercambiándolo por un token de acceso de Anthropic de corta duración. Hay dos formas comunes de obtener el token emitido por Entra:

• Identidad administrada (VMs, App Service, Functions, Container Apps): La carga de trabajo llama al Azure Instance Metadata Service (IMDS) en http://169.254.169.254/metadata/identity/oauth2/token y recibe un JWT para su identidad asignada.
• Entra Workload Identity (pods de AKS): Kubernetes proyecta un token de cuenta de servicio (firmado por el emisor OIDC del clúster de AKS) en el pod en la ruta indicada en AZURE_FEDERATED_TOKEN_FILE. La carga de trabajo intercambia ese token en Entra por un token de acceso emitido por Entra.

En ambos casos, el token emitido por Entra que presentas a Anthropic lleva un emisor de Entra específico del tenant (el paso Configurar Anthropic más abajo muestra la URL exacta que debes registrar) y el ID de objeto de la identidad administrada en los claims sub y oid. Registras ese emisor con Anthropic una sola vez, escribes una regla de federación que coincida con los claims esperados, y tu carga de trabajo intercambia su token de Entra por un token de acceso sk-ant-oat01-... en tiempo de ejecución.

Requisitos previos

• Familiaridad con los conceptos de WIF: cuentas de servicio, emisores de federación y reglas de federación.
• Una suscripción de Azure con permiso para asignar identidades administradas (o configurar Entra Workload Identity en AKS).
• Tu ID de tenant de Microsoft Entra. Encuéntralo en el portal de Azure en Microsoft Entra ID → Overview → Tenant ID.
• Permiso para crear cuentas de servicio, emisores de federación y reglas de federación en Claude Console para tu organización de Anthropic.

Configurar Azure

Configura la identidad para la que Azure emitirá tokens. Elige la ruta que corresponda al lugar donde se ejecuta tu carga de trabajo.

Claims del token

Un token emitido por Entra para una identidad administrada lleva estos claims:

{
  "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 y oid son idénticos (el ID de objeto de la identidad administrada). azp es el ID de aplicación o cliente. Haz la coincidencia con oid para autorizar una identidad específica, o con azp para autorizar cualquier identidad asociada con un registro de aplicación. El claim tid repite tu ID de tenant; hacer la coincidencia con él es una defensa en profundidad, porque la URL del emisor ya fija el tenant.

Configurar Anthropic

Sigue el tutorial de configuración para registrar un emisor de federación, crear una cuenta de servicio de Anthropic y crear una regla de federación en Claude Console. En la Consola, elige la opción de proveedor OIDC y proporciona los valores específicos de Entra que se indican a continuación.

Emisor de federación: Entra publica un documento de descubrimiento OIDC en la URL del emisor específica de cada tenant, así que usa el modo de descubrimiento. Cada tenant de Azure que federes necesita su propio registro de emisor.

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

Regla de federación: Haz la coincidencia con el ID de objeto de la identidad administrada y tu ID de tenant.

{
  "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
}

Adquirir y usar el token

En tiempo de ejecución, tu carga de trabajo obtiene su token de Entra, lo intercambia en POST /v1/oauth/token y usa el token bearer devuelto para llamar a Claude. Cada SDK de Anthropic maneja el intercambio y el bucle de actualización cuando proporcionas un callable proveedor de tokens, como se muestra en los siguientes ejemplos. La pestaña de cURL muestra el flujo sin procesar.

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)

En AKS con Entra Workload Identity

En AKS, el archivo en AZURE_FEDERATED_TOKEN_FILE es un token de cuenta de servicio proyectado por Kubernetes firmado por el emisor OIDC de tu clúster, no un token emitido por Entra. Para mantenerte en la ruta mediada por Entra descrita en esta página, intercambia primero ese token en https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token (grant client_credentials federado), y luego pasa el token de acceso de Entra resultante al SDK de Anthropic como el token de identidad.

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)

Alternativamente, registra el emisor OIDC de tu clúster de AKS directamente con Anthropic y omite el salto a Entra. Consulta Kubernetes para ese patrón.

Verificar la configuración

Desde tu recurso de Azure, ejecuta el intercambio de cURL mostrado anteriormente y confirma que POST /v1/oauth/token devuelve un 200 con un access_token que comienza con sk-ant-oat01- y un valor de expires_in en segundos. Si recibes 400 invalid_grant, consulta Solucionar problemas de un intercambio fallido; la causa más común del lado de Azure es una discrepancia entre la issuer_url que registraste y el claim iss en tu token decodificado. Deben coincidir exactamente. Para tokens de identidad administrada, el valor de iss es https://login.microsoftonline.com/<TENANT_ID>/v2.0 o https://sts.windows.net/<TENANT_ID>/.

Delimitar el alcance de tu regla

Restringe el bloque match de la regla al alcance más estrecho que se ajuste a tu caso de uso:

• Haz coincidir oid como un valor exacto: Establece claims.oid en el ID de objeto completo de la identidad administrada y nunca uses subject_prefix para tokens de Azure.
• Fija tid como defensa en profundidad: La URL del emisor ya fija tu tenant, pero agregar claims.tid protege contra desviaciones de configuración si el registro del emisor se edita más adelante.
• Fija la audiencia: Establece audience en https://api.anthropic.com para que se rechacen los tokens emitidos para otros recursos.
• Usa una regla separada por cada identidad administrada: Crea una regla por identidad en lugar de una regla que autorice varias, para que puedas revocar el acceso de una sola carga de trabajo sin afectar a las demás.

Próximos pasos

• Revisa el modelo de configuración completo en Workload Identity Federation.
• Consulta las guías de proveedores para AWS, Google Cloud, GitHub Actions y Kubernetes.
• Para variables de entorno, archivos de perfil y precedencia de credenciales, consulta la referencia de WIF.