Microsoft Entra IDでWIFを使用する

Azureワークロードは、Microsoft Entra IDが発行したJSON Web Token（JWT）を提示し、それを短命のAnthropicアクセストークンと交換することでClaude APIに対して認証します。セットアップはすべてのAzureプラットフォームで同じ形式に従います。

1. トークンオーディエンスを登録する: Claude APIのオーディエンスを表すアプリ登録をMicrosoft Entraテナントに1つ作成します。テナント内のすべてのワークロードがそれに対するEntraトークンを要求します。
2. プラットフォームに応じたIDを設定する: VM、VM Scale Sets、App Service、Functions、Container AppsではマネージドID、AKSではEntra Workload Identityを使用します。
3. Anthropicを設定する: テナントのEntra発行者を登録し、サービスアカウントを作成し、トークンのクレームに一致するフェデレーションルールを作成します。
4. 実行時に交換する: ワークロードはEntraが発行したトークンをPOST /v1/oauth/tokenでsk-ant-oat01-...形式のAnthropicアクセストークンと交換し、それを使ってClaudeを呼び出します。

どちらのパスでも、Anthropicに提示するトークンには、テナント固有のEntra発行者と、subおよびoidクレームにマネージドIDのオブジェクトIDが含まれます。異なるのは、ワークロードがそのトークンを取得する方法だけです。ワークロードが実行される場所に応じたセクションを選択してください。VM、VM Scale Sets、App Service、Functions、Container Appsの場合はマネージドIDを使用する、AKSの場合はAKSでEntra Workload Identityを使用するを参照してください。



前提条件

• WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
• マネージドIDを割り当てる（またはAKSでEntra Workload Identityを設定する）権限を持つAzureサブスクリプション。
• Microsoft Entraテナントにアプリ登録とサービスプリンシパルを1つ作成する権限（共有のClaude APIオーディエンス）。Entraはテナント内に存在するオーディエンスに対してのみトークンを発行するため、トークン要求が成功する前にトークンオーディエンスを登録するの手順が必要です。
• Microsoft EntraテナントID。AzureポータルのMicrosoft Entra ID → 概要 → テナントIDで確認できます。
• Anthropic組織のClaude Consoleでサービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。



トークンオーディエンスを登録する

Microsoft Entra IDは、要求されたオーディエンスがサービスプリンシパルを持つアプリ登録としてテナント内に存在する場合にのみトークンを発行します。Claude APIのオーディエンスを表すアプリ登録を1つ作成します。テナント内のすべてのワークロードがそれに対するトークンを要求できます。この登録がないと、トークン要求は「resource not found in tenant」エラー（マネージドIDエンドポイントからはAADSTS50001、EntraトークンエンドポイントからはAADSTS500011）で失敗します。

# Claude APIのオーディエンスを表すアプリ登録を作成します。
APP_ID=$(az ad app create --display-name claude-api-federation --query appId -o tsv)

# v2.0アクセストークンを要求し、api://<APP_ID> の識別子URIを設定します。
az ad app update --id "$APP_ID" \
  --identifier-uris "api://$APP_ID" \
  --set api.requestedAccessTokenVersion=2

# テナント内でオーディエンスが解決されるように、サービスプリンシパルを作成します。
az ad sp create --id "$APP_ID"



マネージドIDを使用する

ワークロードがVM、VM Scale Set、App Service、Functions、またはContainer Appsで実行される場合は、このパスを使用します。ワークロードは、プラットフォームのローカルトークンエンドポイントから、割り当てられたマネージドIDに対するEntra発行のJWTを要求し、そのJWTをAnthropicと交換します。



マネージドIDを設定する



Anthropicを設定する

Claude ConsoleでSettings → Workload identityを開き、Connect workloadをクリックしてMicrosoft Entraタイルを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

フェデレーション発行者: ウィザードのToken issuerセレクターで**v2.0 (login.microsoftonline.com)**を選択します。（セレクターのデフォルトはv1です。このデフォルトは、v1.0トークンを発行し続ける古い登録を再利用しているテナントのために存在します。）Entraはテナントごとの発行者URLでOIDCディスカバリードキュメントを公開しているため、ディスカバリーモードを使用してください。フェデレーションする各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一致は、そもそもどのIDがトークンを交換できるかを制限します。詳細はルールのスコープを絞るを参照してください。

フェデレーションルール: マネージドIDのオブジェクトIDとテナントIDに一致させます。本ガイドで設定するv2.0トークンの場合、audience値はオーディエンスアプリ登録のクライアントID（トークンオーディエンスを登録するの<APP_ID> GUID）です。デコードしたトークンの正確な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で交換し、返されたベアラートークンを使用してClaudeを呼び出します。以下の例に示すように、トークンプロバイダーのcallableを指定すると、各Anthropic SDKが交換とリフレッシュのループを処理します。cURLタブは生のフローを示しています。

サンプルは、プラットフォームのトークンエンドポイント（VMとVM Scale SetsではIMDS、App Service、Functions、Container AppsではIDENTITY_ENDPOINTサービス）からマネージドIDトークンを取得します。api://<APP_ID>リソース値の<APP_ID>を、トークンオーディエンスを登録するのオーディエンスアプリ登録のクライアント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."""
    # 複数のユーザー割り当てIDがある場合は、client_id=<IDENTITY_CLIENT_ID>を
    # リクエストパラメータに追加して1つを選択します。
    if endpoint := os.environ.get("IDENTITY_ENDPOINT"):
        # App Service、Functions、Container Apps
        response = requests.get(
            endpoint,
            headers={"X-IDENTITY-HEADER": os.environ["IDENTITY_HEADER"]},
            params={"api-version": "2019-08-01", "resource": AUDIENCE},
            timeout=5,
        )
    else:
        # VMまたはVM Scale Set:Azure Instance Metadata Service(IMDS)
        response = requests.get(
            "http://169.254.169.254/metadata/identity/oauth2/token",
            headers={"Metadata": "true"},
            params={"api-version": "2018-02-01", "resource": AUDIENCE},
            timeout=5,
        )
    response.raise_for_status()
    return response.json()["access_token"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_entra_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Azure"}],
)
print(next(block.text for block in message.content if block.type == "text"))



セットアップを検証する

Azureリソースから、トークンを取得して使用するに示されているcURL交換を実行し、POST /v1/oauth/tokenがsk-ant-oat01-で始まるaccess_tokenと秒単位のexpires_in値を含む200を返すことを確認します。400 invalid_grantの場合は、Entraトークンをデコードし（コマンドについては失敗した交換のトラブルシューティングを参照）、Azure側の最も一般的な原因を確認してください。

• 発行者の不一致: 登録されたissuer_urlはトークンのissクレームと正確に一致する必要があります。v2.0トークンはhttps://login.microsoftonline.com/<TENANT_ID>/v2.0を含みます。デコードされたverクレームが1.0の場合は、トークンがv1.0の場合を参照してください。
• トークンのライフタイム: マネージドIDトークンはiatとexpの間が最大24時間です。発行者がまだウィザードの7500（または1時間のデフォルト）のままの場合は、Anthropicを設定するで説明されているようにmax_jwt_lifetime_secondsを86400に引き上げてください。
• オーディエンスの不一致: ルールのaudienceはトークンのaudと正確に一致する必要があります。本ガイドで設定するv2.0トークンの場合は、オーディエンスアプリ登録のクライアントIDです。
• クレーム名の不一致: トークンに含まれないクレームに一致させるルールは決して通過しません。v1.0トークンはクライアントIDをazpではなくappidに含みます。トークンがv1.0の場合を参照してください。



AKSでEntra Workload Identityを使用する

ワークロードがAKSポッドで実行される場合は、このパスを使用します。Entra Workload Identityは、Kubernetesサービスアカウントをユーザー割り当てマネージドIDとフェデレーションします。Kubernetesは、（AKSクラスターのOIDC発行者によって署名された）サービスアカウントトークンをAZURE_FEDERATED_TOKEN_FILEのパスにあるポッドに投影します。この投影されたトークンはEntraが発行したトークンではないため、このページで説明するEntra仲介パスを維持するには、ワークロードは2段階の交換を実行します。まず投影されたトークンをhttps://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token（フェデレーションclient_credentialsグラント）でEntra発行のアクセストークンと引き換え、次にそのEntraトークンをIDトークンとしてAnthropic SDKに渡します。



Entra Workload Identityを設定する



Anthropicを設定する

Claude ConsoleでSettings → Workload identityを開き、Connect workloadをクリックしてMicrosoft Entraタイルを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

フェデレーション発行者: ウィザードのToken issuerセレクターで**v2.0 (login.microsoftonline.com)**を選択します。（セレクターのデフォルトはv1です。このデフォルトは、v1.0トークンを発行し続ける古い登録を再利用しているテナントのために存在します。）Entraはテナントごとの発行者URLでOIDCディスカバリードキュメントを公開しているため、ディスカバリーモードを使用してください。フェデレーションする各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一致は、そもそもどのIDがトークンを交換できるかを制限します。詳細はルールのスコープを絞るを参照してください。

フェデレーションルール: マネージドIDのオブジェクトIDとテナントIDに一致させます。本ガイドで設定するv2.0トークンの場合、audience値はオーディエンスアプリ登録のクライアントID（トークンオーディエンスを登録するの<APP_ID> GUID）です。デコードしたトークンの正確な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が自動的にリフレッシュします。



トークンを取得して使用する

実行時にポッドは2段階の交換を実行します。Kubernetesが投影したトークン（AZURE_FEDERATED_TOKEN_FILEのファイル）をフェデレーションclient_credentialsアサーションとしてEntraのトークンエンドポイントに送信し、次に得られたEntraアクセストークンをPOST /v1/oauth/tokenで交換します。以下の例に示すように、Entraの取得をトークンプロバイダーのcallableとして指定すると、各Anthropic SDKが2番目の交換とリフレッシュのループを処理します。cURLタブは生のフローを示しています。

サンプルには2つの異なるクライアントIDが登場します。<APP_ID>はトークンオーディエンスを登録するのオーディエンスアプリ登録のクライアントIDで、スコープapi://<APP_ID>/.defaultはそのオーディエンス宛てのトークンをEntraに要求します。$AZURE_CLIENT_IDはWebhookによって注入されるマネージドIDのクライアント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がsk-ant-oat01-で始まるaccess_tokenと秒単位のexpires_in値を含む200を返すことを確認します。400 invalid_grantの場合は、ステップ1のEntra発行トークンをデコードし（コマンドについては失敗した交換のトラブルシューティングを参照）、Azure側の最も一般的な原因を確認してください。

• 発行者の不一致: 登録されたissuer_urlはトークンのissクレームと正確に一致する必要があります。v2.0トークンはhttps://login.microsoftonline.com/<TENANT_ID>/v2.0を含みます。デコードされたverクレームが1.0の場合は、トークンがv1.0の場合を参照してください。
• トークンのライフタイム: テナントのトークンライフタイムポリシーまたはCAEによってclient_credentialsトークンが7500秒を超える場合は、Anthropicを設定するで説明されているように発行者のmax_jwt_lifetime_secondsを引き上げてください。
• オーディエンスの不一致: ルールのaudienceはトークンのaudと正確に一致する必要があります。本ガイドで設定するv2.0トークンの場合は、オーディエンスアプリ登録のクライアントIDです。
• クレーム名の不一致: トークンに含まれないクレームに一致させるルールは決して通過しません。v1.0トークンはクライアントIDをazpではなくappidに含みます。トークンがv1.0の場合を参照してください。



トークンがv1.0の場合

本ガイドではオーディエンスアプリ登録をapi.requestedAccessTokenVersion: 2で設定しているため、示されているすべてのトークンはv2.0です。requestedAccessTokenVersionを未設定のままにしている既存の登録を再利用する場合、Entraは代わりにv1.0トークンを発行します。サンプルトークンをデコードしてverクレームを確認してください。1.0の場合、4つの点が変わります。

• 発行者: issクレームはhttps://login.microsoftonline.com/<TENANT_ID>/v2.0ではなくhttps://sts.windows.net/<TENANT_ID>/です。トークンのissクレームに含まれているとおりに発行者URLを正確に登録してください。2つのURLは同じJWKSを共有しているため、ディスカバリーモードはどちらでも機能します。
• ウィザードのセレクター: Connect workloadウィザードのToken issuerセレクターで、**v2.0 (login.microsoftonline.com)ではなくv1 (sts.windows.net)**を選択します。
• オーディエンス: audクレームは、登録のクライアントIDではなく、resourceとして渡した識別子URI（例: api://<APP_ID>）です。フェデレーションルールのaudienceを、デコードしたトークンの正確なaud値に設定してください。
• クライアントIDクレーム: 呼び出し元IDのクライアントIDはazpではなくappidに現れます。2つのクレームが同じトークンに現れることはないため、azpに一致させるルールはv1.0トークンに対して決して通過しません。

oid、sub、tidクレームは両方のバージョンで同じ値を持つため、本ガイドの残りの部分はそのまま適用されます。



ルールのスコープを絞る

フェデレーションルールは、claimsマップに加えて（またはその代わりに）subject_prefixでトークンのサブジェクトに一致させることができます。フィールドの組み合わせ方については、ルール一致のセマンティクスを参照してください。これらのIDのEntra sub値は固定長の正規GUIDであるため、完全な36文字のオブジェクトIDを含むsubject_prefixはそのサブジェクトにのみ一致します。これはEntraのサブジェクト形式の特性であり、subject_prefix一般の特性ではありません。

ルールのmatchブロックを、ユースケースに合う最も狭いスコープにロックしてください。

• oidを正確な値として一致させる: claims.oidをマネージドIDの完全なオブジェクトIDに設定します。その完全なオブジェクトIDに設定されたsubject_prefixは同等です（Consoleウィザードは両方を設定します）。ワイルドカードや部分的なGUIDのsubject_prefixは意図した以上のIDに一致するため、決して使用しないでください。
• 多層防御としてtidを固定する: 発行者URLはすでにテナントを固定していますが、claims.tidを追加すると、発行者レコードが後で編集された場合の設定のずれを防げます。
• オーディエンスを固定する: audienceをデコードしたトークンの正確なaud値に設定し、他のアプリケーション向けに発行されたトークンが拒否されるようにします。
• マネージドIDごとに個別のルールを使用する: 複数のIDを認可する1つのルールではなく、IDごとに1つのルールを作成します。これにより、他に影響を与えずに単一のワークロードのアクセスを取り消すことができます。



次のステップ

• Workload Identity Federationで完全な設定モデルを確認してください。
• AWS、Google Cloud、GitHub Actions、Kubernetesについては、プロバイダーガイドを参照してください。
• 環境変数、プロファイルファイル、資格情報の優先順位については、WIFリファレンスを参照してください。