Claude Platform Docs
АдминистрированиеПоставщики удостоверений

Использование WIF с Microsoft Entra ID

Настройте федерацию управляемых удостоверений Azure и Entra Workload Identity с Claude API, чтобы ваши рабочие нагрузки Azure могли вызывать Claude без статических ключей API.

Рабочие нагрузки Azure проходят аутентификацию в Claude API, предъявляя «JSON Web Token» (веб-токен JSON), или JWT, выпущенный Microsoft Entra ID, а затем обменивая его на краткосрочный токен доступа Anthropic. Настройка имеет одинаковую структуру на каждой платформе Azure:

  1. Зарегистрируйте аудиторию токена: Создайте одну регистрацию приложения в вашем клиенте (tenant) Microsoft Entra, представляющую аудиторию Claude API. Каждая рабочая нагрузка в клиенте запрашивает токены Entra для неё.
  2. Настройте удостоверение для вашей платформы: «Managed identity» (управляемое удостоверение) на виртуальных машинах, масштабируемых наборах виртуальных машин (VM Scale Sets), App Service, Functions и Container Apps либо Entra Workload Identity на AKS.
  3. Настройте Anthropic: Зарегистрируйте издателя Entra вашего клиента, создайте сервисный аккаунт и напишите правило федерации, соответствующее утверждениям (claims) токена.
  4. Выполните обмен во время выполнения: Ваша рабочая нагрузка обменивает выпущенный Entra токен через POST /v1/oauth/token на токен доступа Anthropic вида sk-ant-oat01-... и вызывает Claude с его помощью.

В обоих вариантах токен, который вы предъявляете Anthropic, содержит специфичного для вашего клиента издателя Entra и идентификатор объекта управляемого удостоверения в утверждениях sub и oid; различается только способ получения этого токена рабочей нагрузкой. Выберите раздел в зависимости от того, где выполняется ваша рабочая нагрузка: Использование управляемого удостоверения для виртуальных машин, VM Scale Sets, App Service, Functions или Container Apps; Использование Entra Workload Identity на AKS для AKS.

Предварительные требования

  • Знакомство с концепциями WIF: сервисные аккаунты, издатели федерации и правила федерации.
  • Подписка Azure с разрешением назначать управляемые удостоверения (или настраивать Entra Workload Identity на AKS).
  • Разрешение на создание одной регистрации приложения и субъекта-службы (service principal) в вашем клиенте Microsoft Entra (общая аудитория Claude API). Entra выпускает токены только для аудитории, существующей в клиенте, поэтому шаг Регистрация аудитории токена обязателен, прежде чем любой запрос токена завершится успешно.
  • Идентификатор вашего клиента Microsoft Entra. Найдите его на портале Azure в разделе Microsoft Entra ID → Overview → Tenant ID.
  • Разрешение на создание сервисных аккаунтов, издателей федерации и правил федерации в Claude Console для вашей организации Anthropic.

Регистрация аудитории токена

Microsoft Entra ID выпускает токен только тогда, когда запрошенная аудитория существует в вашем клиенте в виде регистрации приложения с субъектом-службой. Создайте одну регистрацию приложения, представляющую аудиторию Claude API; каждая рабочая нагрузка в клиенте может запрашивать токены для неё. Без этой регистрации запросы токенов завершаются ошибкой «resource not found in tenant» (AADSTS50001 от конечных точек управляемого удостоверения, AADSTS500011 от конечной точки токенов Entra).

# Создайте регистрацию приложения, представляющую аудиторию Claude API.
APP_ID=$(az ad app create --display-name claude-api-federation --query appId -o tsv)

# Запросите токены доступа v2.0 и задайте URI идентификатора api://<APP_ID>.
az ad app update --id "$APP_ID" \
  --identifier-uris "api://$APP_ID" \
  --set api.requestedAccessTokenVersion=2

# Создайте субъект-службу, чтобы аудитория разрешалась в вашем клиенте.
az ad sp create --id "$APP_ID"

Использование управляемого удостоверения

Используйте этот вариант, если ваша рабочая нагрузка выполняется на виртуальной машине, в VM Scale Set, App Service, Functions или Container Apps. Рабочая нагрузка запрашивает выпущенный Entra JWT для назначенного ей управляемого удостоверения у локальной конечной точки токенов платформы, а затем обменивает этот JWT у Anthropic.

Настройка управляемого удостоверения

  1. Подключите управляемое удостоверение

    Включите назначаемое системой или назначаемое пользователем управляемое удостоверение на вашем ресурсе Azure. На портале Azure откройте ресурс, перейдите в раздел Identity и включите System assigned (или подключите назначаемое пользователем удостоверение).

    После создания удостоверения запишите его Object (principal) ID. Этот GUID присутствует в выпущенном токене одновременно в утверждениях sub и oid, и ваше правило федерации Anthropic будет сопоставляться по нему. Вы можете найти его на странице Identity ресурса; для назначаемого пользователем удостоверения это Object (principal) ID на странице Overview ресурса управляемого удостоверения. (Управляемое удостоверение имеет в Microsoft Entra ID только субъект-службу, а не регистрацию приложения.)

  2. Найдите конечную точку токенов платформы

    После подключения удостоверения платформа предоставляет локальную конечную точку токенов:

    • Виртуальные машины и VM Scale Sets: IMDS по адресу http://169.254.169.254/metadata/identity/oauth2/token с заголовком Metadata: true и api-version=2018-02-01.
    • App Service, Functions и Container Apps: URL из переменной окружения IDENTITY_ENDPOINT с заголовком X-IDENTITY-HEADER, установленным в значение IDENTITY_HEADER, и api-version=2019-08-01. IMDS недоступен на этих платформах.

    Если у ресурса более одного назначаемого пользователем управляемого удостоверения, добавьте client_id=<IDENTITY_CLIENT_ID> в запрос токена, чтобы выбрать одно из них. Azure рекомендует всегда указывать его. Без него результат зависит от того, включено ли на ресурсе также назначаемое системой удостоверение: если да, запрос незаметно переключается на это удостоверение и затем не проходит сопоставление по oid в вашем правиле федерации; если нет, запрос сразу завершается ошибкой, как только подключается второе назначаемое пользователем удостоверение.

  3. Декодируйте пример токена

    Запросите токен у конечной точки и декодируйте его полезную нагрузку, чтобы подтвердить утверждения, по которым должно сопоставляться ваше правило федерации. (Команду декодирования см. в разделе Устранение неполадок при неудачном обмене.) Токен v2.0 для управляемого удостоверения содержит следующие утверждения:

    {
  "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
}
    УтверждениеЗначениеСопоставляйте по нему, когда
    oidИдентификатор объекта управляемого удостоверения, идентичный subВы хотите авторизовать одно конкретное управляемое удостоверение. Это вариант по умолчанию; правило в разделе Настройка Anthropic сопоставляется по нему.
    azpИдентификатор клиента (client ID) вызывающего удостоверенияВы хотите авторизовать каждую рабочую нагрузку, использующую одну общую регистрацию приложения. Для управляемого удостоверения azp уникален для этого удостоверения, поэтому он эквивалентен oid.
    audИдентификатор клиента регистрации приложения аудитории (GUID <APP_ID> из раздела Регистрация аудитории токена)Всегда. Поле audience правила должно точно совпадать со значением aud токена.
    tidИдентификатор вашего клиентаВы хотите эшелонированную защиту. URL издателя уже фиксирует клиента.

    Если утверждение ver декодированного токена равно 1.0, имена и значения утверждений отличаются. Прежде чем продолжить, см. раздел Если ваши токены версии v1.0.

Настройка Anthropic

В Claude Console откройте Settings → Workload identity, нажмите Connect workload и выберите плитку Microsoft Entra. Мастер проведёт вас через регистрацию издателя, создание сервисного аккаунта и создание правила федерации.

Мастер создаёт эти ресурсы за вас. Используйте следующие значения независимо от того, вводите ли вы их в мастере или отправляете в Admin API:

Издатель федерации: Выберите v2.0 (login.microsoftonline.com) в селекторе Token issuer мастера. (По умолчанию в селекторе выбрано v1; это значение по умолчанию существует для клиентов, повторно использующих старые регистрации, которые всё ещё выпускают токены v1.0.) Entra публикует документ обнаружения OIDC по URL издателя для каждого клиента, поэтому используйте режим обнаружения. Каждому клиенту Microsoft Entra, для которого вы настраиваете федерацию, нужна собственная запись издателя.

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

Более длительный допустимый срок действия означает, что утёкший токен Entra дольше остаётся пригодным для обмена. Если токен утёк, рычагом воздействия является отключение правила федерации; строгое сопоставление по oid изначально ограничивает, какие удостоверения могут обменять токен, как описано в разделе Ограничение области действия правила.

Правило федерации: Сопоставляйте по идентификатору объекта управляемого удостоверения и идентификатору вашего клиента. Для токенов v2.0, настраиваемых в этом руководстве, значением audience является идентификатор клиента регистрации приложения аудитории (GUID <APP_ID> из раздела Регистрация аудитории токена). Используйте точное значение aud из вашего декодированного токена.

{
  "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 — это срок действия токена доступа Anthropic, возвращаемого при обмене, а не токена Entra; SDK обновляет его за вас.

Получение и использование токена

Во время выполнения ваша рабочая нагрузка получает свой токен Entra, обменивает его через POST /v1/oauth/token и использует возвращённый bearer-токен для вызова Claude. Каждый SDK Anthropic выполняет обмен и цикл обновления, когда вы передаёте вызываемый объект — поставщик токенов, как показано в следующих примерах. Вкладка cURL показывает необработанный поток.

Примеры получают токен управляемого удостоверения у конечной точки токенов платформы: IMDS на виртуальных машинах и VM Scale Sets или службы IDENTITY_ENDPOINT в App Service, Functions и Container Apps. Замените <APP_ID> в значении ресурса api://<APP_ID> идентификатором клиента регистрации приложения аудитории из раздела Регистрация аудитории токена.

import os

import anthropic
import requests
from anthropic import WorkloadIdentityCredentials

# URI идентификатора регистрации приложения-аудитории (см. раздел «Регистрация аудитории токена»).
AUDIENCE = "api://<APP_ID>"


def fetch_entra_token() -> str:
    """Fetch a managed identity token from the platform's token endpoint."""
    # При нескольких назначаемых пользователем удостоверениях добавьте client_id=<IDENTITY_CLIENT_ID>
    # в параметры запроса, чтобы выбрать одно из них.
    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:
        # ВМ или масштабируемый набор ВМ: 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"))

Проверка настройки

С вашего ресурса Azure выполните обмен через cURL, показанный в разделе Получение и использование токена, и убедитесь, что POST /v1/oauth/token возвращает 200 с access_token, начинающимся с sk-ant-oat01-, и значением expires_in в секундах. Если обмен завершается непрозрачным ответом 401 authentication_error (сообщение Authentication failed), проверьте причину отказа на странице истории аутентификации, затем декодируйте токен Entra (команду см. в разделе Устранение неполадок при неудачном обмене) и проверьте наиболее распространённые причины на стороне Azure:

  • Несовпадение издателя: Зарегистрированный issuer_url должен точно совпадать с утверждением iss токена. Токен v2.0 содержит https://login.microsoftonline.com/<TENANT_ID>/v2.0; если декодированное утверждение ver равно 1.0, см. раздел Если ваши токены версии v1.0.
  • Срок действия токена: Токены управляемых удостоверений имеют интервал до 24 часов между iat и exp. Если у издателя всё ещё установлено значение мастера 7500 (или значение по умолчанию в 1 час), увеличьте max_jwt_lifetime_seconds до 86400, как описано в разделе Настройка Anthropic.
  • Несовпадение аудитории: Значение audience правила должно точно совпадать с aud токена: идентификатор клиента регистрации приложения аудитории для токенов v2.0, настраиваемых в этом руководстве.
  • Несовпадение имени утверждения: Правило, сопоставляющееся по утверждению, которого нет в токене, никогда не проходит. Токены v1.0 содержат идентификатор клиента в appid, а не в azp; см. раздел Если ваши токены версии v1.0.

Использование Entra Workload Identity на AKS

Используйте этот вариант, если ваша рабочая нагрузка выполняется в поде AKS. Entra Workload Identity устанавливает федерацию между сервисным аккаунтом Kubernetes и назначаемым пользователем управляемым удостоверением: Kubernetes проецирует токен сервисного аккаунта (подписанный издателем OIDC кластера AKS) в под по пути, указанному в AZURE_FEDERATED_TOKEN_FILE. Этот проецируемый токен не является токеном, выпущенным Entra, поэтому, чтобы остаться на описанном на этой странице пути через Entra, рабочая нагрузка выполняет двухэтапный обмен: сначала она обменивает проецируемый токен по адресу https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token (федеративный грант client_credentials) на выпущенный Entra токен доступа, а затем передаёт этот токен Entra в SDK Anthropic в качестве токена удостоверения.

Настройка Entra Workload Identity

  1. Включите издателя OIDC и workload identity на вашем кластере

    Включение workload identity устанавливает за вас мутирующий вебхук azure-workload-identity; разворачивайте его вручную только на кластерах, отличных от AKS. Сохраните URL издателя OIDC кластера для федеративных учётных данных, которые вы создадите на одном из следующих шагов.

    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. Создайте назначаемое пользователем управляемое удостоверение

    Сохраните два значения из удостоверения: Client ID указывается в аннотации сервисного аккаунта (и внедряется в под как AZURE_CLIENT_ID), а Object (principal) ID присутствует в виде утверждения oid, по которому сопоставляется ваше правило федерации Anthropic.

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

# Указывается в аннотации сервисного аккаунта; внедряется в pod как AZURE_CLIENT_ID.
IDENTITY_CLIENT_ID=$(az identity show \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --query clientId -o tsv)

# Отображается как claim oid, с которым сопоставляется ваше правило федерации.
IDENTITY_OBJECT_ID=$(az identity show \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --query principalId -o tsv)

  3. Создайте аннотированный сервисный аккаунт Kubernetes

    Вебхук azure-workload-identity считывает аннотацию azure.workload.identity/client-id, чтобы внедрить AZURE_CLIENT_ID в под; примеры в разделе Получение и использование токена считывают это значение из окружения.

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

  4. Создайте федеративные учётные данные на управляемом удостоверении

    Федеративные учётные данные доверяют издателю OIDC вашего кластера для этого конкретного сервисного аккаунта. Значение --audience api://AzureADTokenExchange — это фиксированная аудитория Entra для входящих токенов сервисных аккаунтов Kubernetes; оно не связано с аудиторией Claude API, которую вы зарегистрировали ранее.

    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. Добавьте метку поду и задайте его сервисный аккаунт

    Под должен иметь метку azure.workload.identity/use: "true" и выполняться от имени аннотированного сервисного аккаунта. Затем вебхук внедряет в под AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID и AZURE_TENANT_ID. Файл по пути AZURE_FEDERATED_TOKEN_FILE содержит проецируемый Kubernetes токен сервисного аккаунта, подписанный издателем OIDC кластера 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. Декодируйте пример токена

    Токен, который видит ваше правило федерации Anthropic, — это не проецируемый файл, а выпущенный Entra токен, возвращаемый обменом client_credentials. Изнутри помеченного пода выполните шаг 1 примера cURL из раздела Получение и использование токена и декодируйте результат. Он имеет ту же структуру утверждений, что и в варианте с управляемым удостоверением:

    {
  "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 и oid — это идентификатор объекта управляемого удостоверения, aud — идентификатор клиента регистрации приложения аудитории, а azp — идентификатор клиента управляемого удостоверения (значение AZURE_CLIENT_ID). Срок действия отличается от варианта с управляемым удостоверением: токены client_credentials по умолчанию имеют случайный интервал от 60 до 90 минут между iat и exp, а не 24 часа.

Настройка Anthropic

В Claude Console откройте Settings → Workload identity, нажмите Connect workload и выберите плитку Microsoft Entra. Мастер проведёт вас через регистрацию издателя, создание сервисного аккаунта и создание правила федерации.

Мастер создаёт эти ресурсы за вас. Используйте следующие значения независимо от того, вводите ли вы их в мастере или отправляете в Admin API:

Издатель федерации: Выберите v2.0 (login.microsoftonline.com) в селекторе Token issuer мастера. (По умолчанию в селекторе выбрано v1; это значение по умолчанию существует для клиентов, повторно использующих старые регистрации, которые всё ещё выпускают токены v1.0.) Entra публикует документ обнаружения OIDC по URL издателя для каждого клиента, поэтому используйте режим обнаружения. Каждому клиенту Microsoft Entra, для которого вы настраиваете федерацию, нужна собственная запись издателя.

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

Более длительный допустимый срок действия означает, что утёкший токен Entra дольше остаётся пригодным для обмена. Если токен утёк, рычагом воздействия является отключение правила федерации; строгое сопоставление по oid изначально ограничивает, какие удостоверения могут обменять токен, как описано в разделе Ограничение области действия правила.

Правило федерации: Сопоставляйте по идентификатору объекта управляемого удостоверения и идентификатору вашего клиента. Для токенов v2.0, настраиваемых в этом руководстве, значением audience является идентификатор клиента регистрации приложения аудитории (GUID <APP_ID> из раздела Регистрация аудитории токена). Используйте точное значение aud из вашего декодированного токена.

{
  "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 — это срок действия токена доступа Anthropic, возвращаемого при обмене, а не токена Entra; SDK обновляет его за вас.

Получение и использование токена

Во время выполнения под выполняет двухэтапный обмен: он отправляет проецируемый Kubernetes токен (файл по пути AZURE_FEDERATED_TOKEN_FILE) на конечную точку токенов Entra в качестве федеративного утверждения client_credentials, а затем обменивает полученный токен доступа Entra через POST /v1/oauth/token. Каждый SDK Anthropic выполняет второй обмен и цикл обновления, когда вы передаёте получение токена Entra в виде вызываемого объекта — поставщика токенов, как показано в следующих примерах. Вкладка cURL показывает необработанный поток.

В примерах фигурируют два разных идентификатора клиента. <APP_ID> — это идентификатор клиента регистрации приложения аудитории из раздела Регистрация аудитории токена; область api://<APP_ID>/.default запрашивает у Entra токен, адресованный этой аудитории. $AZURE_CLIENT_ID — это идентификатор клиента управляемого удостоверения, внедряемый вебхуком, который идентифицирует вызывающую сторону. Не подставляйте один вместо другого.

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"))

Проверка настройки

Изнутри помеченного пода выполните обмен через cURL, показанный в разделе Получение и использование токена, и убедитесь, что POST /v1/oauth/token возвращает 200 с access_token, начинающимся с sk-ant-oat01-, и значением expires_in в секундах. Если обмен завершается непрозрачным ответом 401 authentication_error (сообщение Authentication failed), проверьте причину отказа на странице истории аутентификации, затем декодируйте выпущенный Entra токен из шага 1 (команду см. в разделе Устранение неполадок при неудачном обмене) и проверьте наиболее распространённые причины на стороне Azure:

  • Несовпадение издателя: Зарегистрированный issuer_url должен точно совпадать с утверждением iss токена. Токен v2.0 содержит https://login.microsoftonline.com/<TENANT_ID>/v2.0; если декодированное утверждение ver равно 1.0, см. раздел Если ваши токены версии v1.0.
  • Срок действия токена: Если политика срока действия токенов клиента или CAE продлевает токен client_credentials сверх 7500 секунд, увеличьте max_jwt_lifetime_seconds издателя, как описано в разделе Настройка Anthropic.
  • Несовпадение аудитории: Значение audience правила должно точно совпадать с aud токена: идентификатор клиента регистрации приложения аудитории для токенов v2.0, настраиваемых в этом руководстве.
  • Несовпадение имени утверждения: Правило, сопоставляющееся по утверждению, которого нет в токене, никогда не проходит. Токены v1.0 содержат идентификатор клиента в appid, а не в azp; см. раздел Если ваши токены версии v1.0.

Если ваши токены версии v1.0

Это руководство настраивает регистрацию приложения аудитории с api.requestedAccessTokenVersion: 2, поэтому каждый показанный в нём токен имеет версию v2.0. Если вы повторно используете существующую регистрацию, в которой requestedAccessTokenVersion не задано, Entra вместо этого выпускает токены v1.0. Декодируйте пример токена и проверьте его утверждение ver; если оно равно 1.0, меняются четыре вещи:

  • Издатель: Утверждение iss равно https://sts.windows.net/<TENANT_ID>/ вместо https://login.microsoftonline.com/<TENANT_ID>/v2.0. Зарегистрируйте URL издателя точно в том виде, в каком он содержится в утверждении iss вашего токена. Оба URL используют один и тот же JWKS, поэтому режим обнаружения работает для любого из них.
  • Селектор мастера: Выберите v1 (sts.windows.net) в селекторе Token issuer мастера Connect workload вместо v2.0 (login.microsoftonline.com).
  • Аудитория: Утверждение aud — это URI идентификатора, который вы передали как resource (например, api://<APP_ID>), а не идентификатор клиента регистрации. Установите audience правила федерации в точное значение aud из вашего декодированного токена.
  • Утверждение идентификатора клиента: Идентификатор клиента вызывающего удостоверения присутствует в appid, а не в azp. Эти два утверждения никогда не встречаются в одном токене, поэтому правило, сопоставляющееся по azp, никогда не проходит для токена v1.0.

Утверждения oid, sub и tid содержат одинаковые значения в обеих версиях, поэтому остальная часть этого руководства применяется без изменений.

Ограничение области действия правила

Правило федерации может сопоставлять субъект токена с помощью subject_prefix в дополнение к карте claims (или вместо неё); о том, как сочетаются поля, см. раздел Семантика сопоставления правил. Значения sub в Entra для этих удостоверений — канонические GUID фиксированной длины, поэтому subject_prefix, содержащий полный 36-символьный идентификатор объекта, соответствует только этому субъекту; это свойство формата субъекта Entra, а не subject_prefix в целом.

Ограничьте блок match правила самой узкой областью, подходящей для вашего сценария:

  • Сопоставляйте oid как точное значение: Установите claims.oid в полный идентификатор объекта управляемого удостоверения. subject_prefix, установленный в этот полный идентификатор объекта, эквивалентен (мастер Console задаёт оба); никогда не используйте подстановочный знак или subject_prefix с частичным GUID, который соответствует большему числу удостоверений, чем вы предполагаете.
  • Зафиксируйте tid для эшелонированной защиты: URL издателя уже фиксирует ваш клиент, но добавление claims.tid защищает от дрейфа конфигурации, если запись издателя будет позже отредактирована.
  • Зафиксируйте аудиторию: Установите audience в точное значение aud из вашего декодированного токена, чтобы токены, выпущенные для других приложений, отклонялись.
  • Используйте отдельное правило для каждого управляемого удостоверения: Создавайте по одному правилу для каждого удостоверения, а не одно правило, авторизующее несколько, чтобы вы могли отозвать доступ одной рабочей нагрузки, не затрагивая остальные.

Следующие шаги

Was this page helpful?