Microsoft Entra IDでWIFを使用する

Azureワークロードは、Microsoft Entra IDによって発行された「JSON Web Token」（JSONウェブトークン）、すなわちJWTを提示し、それを短期間有効なAnthropicアクセストークンと交換することでClaude APIに対して認証を行います。セットアップはすべてのAzureプラットフォームで同じ構成に従います。

1. トークンオーディエンスを登録する： Microsoft Entraテナントに1つのアプリ登録を作成し、Claude APIオーディエンスを表します。テナント内のすべてのワークロードがこれに対して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はテナントごとの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一致により、そもそもトークンを交換できる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は、Entraトークンではなく、交換が返すAnthropicアクセストークンの有効期間です。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スケールセット: 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が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はテナントごとの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一致により、そもそもトークンを交換できる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は、Entraトークンではなく、交換が返すAnthropicアクセストークンの有効期間です。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はマネージドIDのクライアントIDで、Webhookによって注入され、呼び出し元を識別します。一方を他方に置き換えないでください。

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が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に個別のルールを使用する： 複数を認可する1つのルールではなく、各IDに1つのルールを作成してください。これにより、他に影響を与えることなく単一のワークロードのアクセスを取り消すことができます。



次のステップ

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