• Mensagens
  • Agentes Gerenciados
  • Administração
Search...
⌘K
Organização
API de AdministraçãoWorkspaces
Autenticação
Visão geralWorkload Identity FederationReferência de WIF
AWSGoogle CloudMicrosoft AzureGitHub ActionsKubernetesSPIFFEOkta
Monitoramento
API de Uso e CustoAPI de Limites de TaxaAPI de Análise do Claude Code
Dados e conformidade
Residência de dadosAPI e retenção de dados
API de Conformidade
Visão geralObter acessoFeed de AtividadesChats, arquivos e projetosOrganizações, usuários, funções e gruposProjetar sua integraçãoErrosPerguntas frequentes
Log in
Microsoft Azure
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
Administração/Provedores de identidade

Usar WIF com o Microsoft Azure

Federe identidades gerenciadas do Azure e o Entra Workload Identity com a API do Claude para que suas cargas de trabalho do Azure possam chamar o Claude sem chaves de API estáticas.

As cargas de trabalho do Azure se autenticam na API do Claude apresentando um "JSON Web Token" (token web JSON), ou JWT, emitido pelo Microsoft Entra ID e, em seguida, trocando-o por um token de acesso de curta duração da Anthropic. Há duas maneiras comuns de obter o token emitido pelo Entra:

  • Identidade gerenciada (VMs, App Service, Functions, Container Apps): A carga de trabalho chama o Azure Instance Metadata Service (IMDS) em http://169.254.169.254/metadata/identity/oauth2/token e recebe um JWT para sua identidade atribuída.
  • Entra Workload Identity (pods do AKS): O Kubernetes projeta um token de conta de serviço (assinado pelo emissor OIDC do cluster AKS) no pod, no caminho indicado em AZURE_FEDERATED_TOKEN_FILE. A carga de trabalho troca esse token no Entra por um token de acesso emitido pelo Entra.

Em ambos os casos, o token emitido pelo Entra que você apresenta à Anthropic carrega um emissor Entra específico do tenant (a etapa Configurar a Anthropic abaixo mostra a URL exata a registrar) e o object ID da identidade gerenciada nas claims sub e oid. Você registra esse emissor na Anthropic uma única vez, escreve uma regra de federação que corresponda às claims esperadas, e sua carga de trabalho troca seu token do Entra por um token de acesso sk-ant-oat01-... em tempo de execução.

Alternativamente, os pods do AKS podem pular a troca com o Entra e apresentar o token de conta de serviço projetado pelo Kubernetes diretamente à Anthropic. Esse caminho registra o emissor OIDC do seu cluster AKS na Anthropic em vez do seu tenant do Entra. Consulte Kubernetes para esse fluxo.

Pré-requisitos

  • Familiaridade com os conceitos de WIF: contas de serviço, emissores de federação e regras de federação.
  • Uma assinatura do Azure com permissão para atribuir identidades gerenciadas (ou configurar o Entra Workload Identity no AKS).
  • Seu ID de tenant do Microsoft Entra. Encontre-o no portal do Azure em Microsoft Entra ID → Overview → Tenant ID.
  • Permissão para criar contas de serviço, emissores de federação e regras de federação no Claude Console para sua organização da Anthropic.

Configurar o Azure

Configure a identidade para a qual o Azure emitirá tokens. Escolha o caminho que corresponde ao local onde sua carga de trabalho é executada.

Claims do token

Um token emitido pelo Entra para uma identidade gerenciada carrega estas 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 e oid são idênticos (o object ID da identidade gerenciada). azp é o ID da aplicação ou do cliente. Faça a correspondência com oid para autorizar uma identidade específica, ou com azp para autorizar qualquer identidade associada a um registro de aplicação. A claim tid repete seu ID de tenant; fazer a correspondência com ela é uma camada adicional de defesa, porque a URL do emissor já fixa o tenant.

Configurar a Anthropic

Siga o passo a passo de configuração para registrar um emissor de federação, criar uma conta de serviço da Anthropic e criar uma regra de federação no Claude Console. No Console, escolha a opção de provedor OIDC e forneça os valores específicos do Entra a seguir.

Emissor de federação: O Entra publica um documento de descoberta OIDC na URL do emissor específica do tenant, então use o modo de descoberta. Cada tenant do Azure que você federar precisa de seu próprio registro de emissor.

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

Dependendo da versão do token, a claim iss pode ser https://sts.windows.net/<TENANT_ID>/ em vez disso. Decodifique seu token de identidade gerenciada (a seção Verificar abaixo mostra como) e registre o valor de iss que ele contiver. As duas URLs compartilham o mesmo JWKS, então o modo de descoberta funciona para qualquer uma delas.

Regra de federação: Faça a correspondência com o object ID da identidade gerenciada e seu 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
}

Obter e usar o token

Em tempo de execução, sua carga de trabalho busca seu token do Entra, troca-o em POST /v1/oauth/token e usa o bearer token retornado para chamar o Claude. Cada SDK da Anthropic lida com o loop de troca e renovação quando você fornece um callable provedor de token, conforme mostrado nos exemplos a seguir. A aba cURL mostra o fluxo bruto.

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)

No AKS com Entra Workload Identity

No AKS, o arquivo em AZURE_FEDERATED_TOKEN_FILE é um token de conta de serviço projetado pelo Kubernetes, assinado pelo emissor OIDC do seu cluster, e não um token emitido pelo Entra. Para permanecer no caminho mediado pelo Entra descrito nesta página, troque esse token em https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token (grant client_credentials federado) primeiro e, em seguida, passe o token de acesso do Entra resultante para o SDK da Anthropic como o token de identidade.

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, registre o emissor OIDC do seu cluster AKS diretamente na Anthropic e pule a etapa do Entra. Consulte Kubernetes para esse padrão.

Verificar a configuração

A partir do seu recurso do Azure, execute a troca via cURL mostrada anteriormente e confirme que POST /v1/oauth/token retorna um 200 com um access_token começando com sk-ant-oat01- e um valor expires_in em segundos. Em caso de 400 invalid_grant, consulte Solucionar problemas de uma troca com falha; a causa mais comum do lado do Azure é uma incompatibilidade entre a issuer_url que você registrou e a claim iss no seu token decodificado. Elas devem corresponder exatamente. Para tokens de identidade gerenciada, o valor de iss é https://login.microsoftonline.com/<TENANT_ID>/v2.0 ou https://sts.windows.net/<TENANT_ID>/.

Definir o escopo da sua regra

A claim oid é o GUID de uma identidade gerenciada e não tem prefixo estável. Um subject_prefix com * corresponde a identidades arbitrárias no tenant, então qualquer carga de trabalho que possua uma identidade gerenciada poderia obter um token federado da Anthropic.

Restrinja o bloco match da regra ao escopo mais estreito que atenda ao seu caso de uso:

  • Corresponda oid como um valor exato: Defina claims.oid como o object ID completo da identidade gerenciada e nunca use subject_prefix para tokens do Azure.
  • Fixe tid como defesa em profundidade: A URL do emissor já fixa seu tenant, mas adicionar claims.tid protege contra desvios de configuração caso o registro do emissor seja editado posteriormente.
  • Fixe a audiência: Defina audience como https://api.anthropic.com para que tokens emitidos para outros recursos sejam rejeitados.
  • Use uma regra separada por identidade gerenciada: Crie uma regra por identidade em vez de uma regra que autorize várias, para que você possa revogar o acesso de uma única carga de trabalho sem afetar as outras.

Próximos passos

  • Revise o modelo de configuração completo em Workload Identity Federation.
  • Consulte os guias de provedores para AWS, Google Cloud, GitHub Actions e Kubernetes.
  • Para variáveis de ambiente, arquivos de perfil e precedência de credenciais, consulte a referência de WIF.

Was this page helpful?

  • Pré-requisitos
  • Configurar o Azure
  • Claims do token
  • Configurar a Anthropic
  • Obter e usar o token
  • No AKS com Entra Workload Identity
  • Verificar a configuração
  • Definir o escopo da sua regra
  • Próximos passos