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

Использование 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:

Зарегистрируйте аудиторию токена: Создайте одну регистрацию приложения в вашем тенанте Microsoft Entra, представляющую аудиторию Claude API. Каждая рабочая нагрузка в тенанте запрашивает токены Entra для неё.
Настройте удостоверение для вашей платформы: Управляемое удостоверение на виртуальных машинах, масштабируемых наборах виртуальных машин, App Service, Functions и Container Apps, либо Entra Workload Identity на AKS.
Настройте Anthropic: Зарегистрируйте издателя Entra вашего тенанта, создайте учётную запись службы и напишите правило федерации, соответствующее утверждениям токена.
Выполните обмен во время выполнения: Ваша рабочая нагрузка обменивает свой токен, выпущенный Entra, через POST /v1/oauth/token на токен доступа Anthropic вида sk-ant-oat01-... и вызывает Claude с его помощью.

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

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

Знакомство с концепциями WIF: учётными записями служб, издателями федерации и правилами федерации.
Подписка Azure с разрешением назначать управляемые удостоверения (или настраивать Entra Workload Identity на AKS).
Разрешение на создание одной регистрации приложения и субъекта-службы в вашем тенанте 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"

Используйте формат URI идентификатора api://<APP_ID>. Entra ограничивает URI идентификаторов вида https:// проверенными доменами вашего собственного тенанта, поэтому URI наподобие https://api.anthropic.com не может быть зарегистрирован в большинстве тенантов; api://<APP_ID> принимается везде. При requestedAccessTokenVersion: 2 токены для этой аудитории имеют версию v2.0, что и предполагается в данном руководстве. Если вы повторно используете существующую регистрацию, которая выпускает токены v1.0, см. раздел Если ваши токены имеют версию v1.0.

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

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

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

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

Декодируйте образец токена

Запросите токен у конечной точки и декодируйте его полезную нагрузку, чтобы подтвердить утверждения, по которым должно сопоставляться ваше правило федерации. (Команду декодирования см. в разделе Устранение неполадок при неудачном обмене.) Токен 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`	Идентификатор клиента вызывающего удостоверения	Вы хотите авторизовать каждую рабочую нагрузку, использующую одну регистрацию приложения. Для управляемого удостоверения `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
}

Рабочим нагрузкам с управляемым удостоверением требуется max_jwt_lifetime_seconds: 86400. Azure выпускает токены управляемого удостоверения с интервалом до 24 часов между iat и exp, поскольку кэширует токен каждого ресурса на этот период и не предоставляет способа принудительно обновить его раньше, а значение по умолчанию издателя в 1 час отклоняет такие токены с ошибкой invalid_grant. Плитка Microsoft Entra в мастере Connect workload создаёт издателя с max_jwt_lifetime_seconds, установленным в 7500, и не предоставляет поля для изменения этого значения при создании, поэтому завершите работу мастера, затем откройте Settings → Workload identity → Issuers, отредактируйте издателя и увеличьте значение до 86400. Вы также можете обновить издателя через Admin API.

Более длительный допустимый срок действия означает, что утёкший токен 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 на виртуальных машинах и масштабируемых наборах виртуальных машин или службы IDENTITY_ENDPOINT на App Service, Functions и Container Apps. Замените <APP_ID> в значении ресурса api://<APP_ID> на идентификатор клиента регистрации приложения аудитории из раздела Регистрация аудитории токена.

Если ваша рабочая нагрузка уже использует клиентскую библиотеку Azure Identity, передайте её механизм получения токена (DefaultAzureCredential с областью api://<APP_ID>/.default) в качестве поставщика токена удостоверения вместо прямого вызова конечных точек токенов. Библиотека выбирает правильную конечную точку на каждой платформе Azure, включая AKS с Entra Workload Identity.

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

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

С вашего ресурса Azure выполните обмен cURL, показанный в разделе Получение и использование токена, и убедитесь, что POST /v1/oauth/token возвращает 200 с access_token, начинающимся с sk-ant-oat01-, и значением expires_in в секундах. При 400 invalid_grant декодируйте токен 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 в качестве токена удостоверения.

Поды AKS могут в качестве альтернативы пропустить обмен через Entra и предъявить спроецированный Kubernetes токен учётной записи службы напрямую Anthropic. В этом варианте у Anthropic регистрируется издатель OIDC вашего кластера AKS вместо вашего тенанта Entra. См. Использование WIF с Kubernetes для описания этого потока.

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

Включите издателя 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)

Создайте назначаемое пользователем управляемое удостоверение

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

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

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

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

Создайте аннотированную учётную запись службы 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>
Создайте федеративные учётные данные на управляемом удостоверении
Федеративные учётные данные устанавливают доверие к издателю 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
Добавьте метку поду и задайте его учётную запись службы
Под должен иметь метку 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
Декодируйте образец токена
Токен, который видит ваше правило федерации 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

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

Плитка Microsoft Entra в мастере Connect workload создаёт издателя с max_jwt_lifetime_seconds, установленным в 7500 (чуть более 2 часов), что покрывает срок действия токенов client_credentials по умолчанию от 60 до 90 минут. Политика срока действия токенов тенанта или «Continuous Access Evaluation» (непрерывная оценка доступа), или CAE, может продлить этот срок. Если разница между exp и iat вашего декодированного токена превышает 7500 секунд, отредактируйте издателя в Settings → Workload identity → Issuers и увеличьте max_jwt_lifetime_seconds соответственно, иначе обмены будут завершаться ошибкой invalid_grant. Если в вашем тенанте также выполняются рабочие нагрузки с управляемым удостоверением из раздела Использование управляемого удостоверения, используйте значение 86400 из того раздела, которое покрывает оба варианта.

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

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

Во время выполнения под выполняет двухэтапный обмен: он отправляет спроецированный 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 — это идентификатор клиента управляемого удостоверения, внедрённый веб-хуком, и он идентифицирует вызывающую сторону. Не подставляйте один вместо другого.

Если ваша рабочая нагрузка уже использует клиентскую библиотеку Azure Identity, передайте её механизм получения токена (DefaultAzureCredential с областью api://<APP_ID>/.default) в качестве поставщика токена удостоверения вместо самостоятельного выполнения двухэтапного обмена. Библиотека считывает те же переменные окружения AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID и AZURE_TENANT_ID и обрабатывает обмен через Entra.

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

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

Изнутри пода с меткой выполните обмен cURL, показанный в разделе Получение и использование токена, и убедитесь, что POST /v1/oauth/token возвращает 200 с access_token, начинающимся с sk-ant-oat01-, и значением expires_in в секундах. При 400 invalid_grant декодируйте токен, выпущенный 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 в целом.

Каждое удостоверение в вашем тенанте может запросить токен для зарегистрированной аудитории, поэтому audience и tid сами по себе не идентифицируют конкретную рабочую нагрузку. Правило, в котором отсутствует сопоставление по oid (или azp/appid) либо используется подстановочный или частичный GUID в subject_prefix, авторизует каждое управляемое удостоверение и каждый субъект-службу в тенанте.

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

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

Дальнейшие шаги

Ознакомьтесь с полной моделью конфигурации в разделе Workload Identity Federation.
См. руководства по провайдерам для AWS, Google Cloud, GitHub Actions и Kubernetes.
О переменных окружения, файлах профилей и приоритете учётных данных см. в справочнике по WIF.

Was this page helpful?

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

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

Зарегистрируйте аудиторию токена: Создайте одну регистрацию приложения в вашем тенанте Microsoft Entra, представляющую аудиторию Claude API. Каждая рабочая нагрузка в тенанте запрашивает токены Entra для неё.
Настройте удостоверение для вашей платформы: Управляемое удостоверение на виртуальных машинах, масштабируемых наборах виртуальных машин, App Service, Functions и Container Apps, либо Entra Workload Identity на AKS.
Настройте Anthropic: Зарегистрируйте издателя Entra вашего тенанта, создайте учётную запись службы и напишите правило федерации, соответствующее утверждениям токена.
Выполните обмен во время выполнения: Ваша рабочая нагрузка обменивает свой токен, выпущенный Entra, через POST /v1/oauth/token на токен доступа Anthropic вида sk-ant-oat01-... и вызывает Claude с его помощью.

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

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

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

# Создайте регистрацию приложения, представляющую аудиторию 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"

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

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

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

Декодируйте образец токена

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

Настройка Anthropic

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

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

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

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

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

Несоответствие издателя: Зарегистрированный 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

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

Включите издателя 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)

Создайте назначаемое пользователем управляемое удостоверение

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

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

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

Создайте аннотированную учётную запись службы 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>
Создайте федеративные учётные данные на управляемом удостоверении
Федеративные учётные данные устанавливают доверие к издателю 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
Добавьте метку поду и задайте его учётную запись службы
Под должен иметь метку 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
Декодируйте образец токена
Токен, который видит ваше правило федерации 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

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

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

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

Если ваша рабочая нагрузка уже использует клиентскую библиотеку Azure Identity, передайте её механизм получения токена (DefaultAzureCredential с областью api://<APP_ID>/.default) в качестве поставщика токена удостоверения вместо самостоятельного выполнения двухэтапного обмена. Библиотека считывает те же переменные окружения AZURE_FEDERATED_TOKEN_FILE, AZURE_CLIENT_ID и AZURE_TENANT_ID и обрабатывает обмен через Entra.

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(message.content[0].text)

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

Несоответствие издателя: Зарегистрированный 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

Издатель: Утверждение 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.

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

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

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

Дальнейшие шаги

Ознакомьтесь с полной моделью конфигурации в разделе Workload Identity Federation.
См. руководства по провайдерам для AWS, Google Cloud, GitHub Actions и Kubernetes.
О переменных окружения, файлах профилей и приоритете учётных данных см. в справочнике по WIF.

Was this page helpful?

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

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

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

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

Настройка Anthropic

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

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

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

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

Настройка Anthropic

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

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

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

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

Дальнейшие шаги

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

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

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

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

Настройка Anthropic

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

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

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

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

Настройка Anthropic

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

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

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

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

Дальнейшие шаги

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

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

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

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

Настройка Anthropic

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

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

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

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

Настройка Anthropic

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

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

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

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

Дальнейшие шаги

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

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

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

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

Настройка Anthropic

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

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

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

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

Настройка Anthropic

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

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

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

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

Дальнейшие шаги