Claude Platform Docs
管理IDプロバイダー

Microsoft Entra ID で WIF を使用する

Azure マネージド ID と Entra Workload Identity を Claude API とフェデレーションし、Azure ワークロードが静的な APIキーなしで Claude を呼び出せるようにします。

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

  1. トークンのオーディエンスを登録する: Microsoft Entra テナントに、Claude API のオーディエンスを表すアプリ登録を 1 つ作成します。テナント内のすべてのワークロードは、このオーディエンス向けの Entra トークンを要求します。
  2. プラットフォームに応じた ID をセットアップする: VM、VM Scale Sets、App Service、Functions、Container Apps ではマネージド ID、AKS では Entra Workload Identity を使用します。
  3. Anthropic を構成する: テナントの Entra 発行者（issuer）を登録し、サービスアカウントを作成し、トークンのクレームに一致するフェデレーションルールを記述します。
  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 → Overview → Tenant 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 を構成する

  1. マネージド ID をアタッチする

    Azure リソースでシステム割り当てまたはユーザー割り当てのマネージド ID を有効にします。Azure ポータルでリソースを開き、Identity に移動して System assigned をオンにします（またはユーザー割り当て ID をアタッチします）。

    ID が作成されたら、その Object (principal) ID を控えておきます。この GUID は発行されるトークンの sub クレームと oid クレームの両方に現れ、Anthropic のフェデレーションルールはこれに対して照合を行います。リソースの Identity ページで確認できます。ユーザー割り当て ID の場合は、マネージド ID リソースの Overview ページにある Object (principal) ID です。（マネージド ID は Microsoft Entra ID 内にサービスプリンシパルのみを持ち、アプリ登録は持ちません。）

  2. プラットフォームのトークンエンドポイントを確認する

    ID がアタッチされると、プラットフォームはローカルトークンエンドポイントを公開します。

    • VM および 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: 環境変数 IDENTITY_ENDPOINT の URL。ヘッダー X-IDENTITY-HEADER に IDENTITY_HEADER の値を設定し、api-version=2019-08-01 を指定します。これらのプラットフォームでは IMDS には到達できません。

    リソースに複数のユーザー割り当てマネージド ID がある場合は、トークン要求に client_id=<IDENTITY_CLIENT_ID> を追加して 1 つを選択します。Azure は常にこれを指定することを推奨しています。指定しない場合、結果はリソースでシステム割り当て ID も有効になっているかどうかに依存します。有効になっている場合、要求は暗黙的にその ID にフォールバックし、その後フェデレーションルールの oid 照合に失敗します。有効になっていない場合、2 つ目のユーザー割り当て ID がアタッチされた時点で要求は即座に失敗します。

  3. サンプルトークンをデコードする

    エンドポイントからトークンを要求し、そのペイロードをデコードして、フェデレーションルールが照合する必要のあるクレームを確認します。（デコードコマンドについては、失敗した交換のトラブルシューティングを参照してください。）マネージド ID 用の 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マネージド ID のオブジェクト ID。sub と同一特定の 1 つのマネージド ID を認可したい場合。これがデフォルトであり、Anthropic を構成するのルールはこれに照合します。
    azp呼び出し元 ID のクライアント ID1 つのアプリ登録を共有するすべてのワークロードを認可したい場合。マネージド ID の場合、azp はその ID に固有であるため、oid と同等です。
    audオーディエンスアプリ登録のクライアント ID（トークンのオーディエンスを登録するの <APP_ID> GUID）常に。ルールの audience フィールドはトークンの aud 値と完全に一致する必要があります。
    tidテナント ID多層防御を行いたい場合。発行者 URL がすでにテナントを固定しています。

    デコードしたトークンの ver クレームが 1.0 の場合、クレーム名と値が異なります。続行する前にトークンが v1.0 の場合を参照してください。

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 が 200 を返し、sk-ant-oat01- で始まる access_token と秒単位の 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 の場合を参照してください。
  • トークンの有効期間: マネージド 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 を構成する

  1. クラスターで OIDC 発行者とワークロード ID を有効にする

    ワークロード ID を有効にすると、azure-workload-identity ミューテーティング Webhook が自動的にインストールされます。手動でデプロイするのは AKS 以外のクラスターの場合のみです。後の手順で作成するフェデレーション資格情報のために、クラスターの OIDC 発行者 URL を取得しておきます。

    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. ユーザー割り当てマネージド ID を作成する

    ID から 2 つの値を取得します。Client ID はサービスアカウントのアノテーションに設定し（ポッドには AZURE_CLIENT_ID として注入されます）、Object (principal) ID は Anthropic のフェデレーションルールが照合する oid クレームとして現れます。

    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)

# フェデレーションルールが照合する oid クレームとして表示されます。
IDENTITY_OBJECT_ID=$(az identity show \
  --resource-group <RESOURCE_GROUP> \
  --name claude-inference-identity \
  --query principalId -o tsv)

  3. アノテーション付きの Kubernetes サービスアカウントを作成する

    azure-workload-identity Webhook は 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. マネージド ID にフェデレーション資格情報を作成する

    フェデレーション資格情報は、その特定のサービスアカウントについてクラスターの OIDC 発行者を信頼します。--audience api://AzureADTokenExchange の値は、受信する Kubernetes サービスアカウントトークンに対する Entra の固定オーディエンスであり、先に登録した 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" ラベルが必要で、アノテーション付きのサービスアカウントとして実行する必要があります。すると Webhook が AZURE_FEDERATED_TOKEN_FILE、AZURE_CLIENT_ID、AZURE_TENANT_ID をポッドに注入します。AZURE_FEDERATED_TOKEN_FILE のファイルには、AKS クラスターの OIDC 発行者によって署名された、Kubernetes が投影したサービスアカウントトークンが含まれます。

    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 のフェデレーションルールが参照するトークンは投影されたファイルではなく、client_credentials 交換によって返される Entra 発行のトークンです。ラベル付きポッドの内部から、トークンを取得して使用するの cURL サンプルのステップ 1 を実行し、結果をデコードします。マネージド ID 経路と同じクレーム構造を持ちます。

    {
  "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 はマネージド ID のオブジェクト ID、aud はオーディエンスアプリ登録のクライアント ID、azp はマネージド ID のクライアント ID（AZURE_CLIENT_ID の値）です。有効期間はマネージド ID 経路と異なります。client_credentials トークンは、iat と exp の間がデフォルトで 24 時間ではなく、60 〜 90 分のランダムな期間になります。

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 が 200 を返し、sk-ant-oat01- で始まる access_token と秒単位の expires_in 値が含まれていることを確認します。交換が不透明な 401 authentication_error レスポンス（メッセージ Authentication failed）で失敗した場合は、認証履歴ページで拒否理由を確認し、ステップ 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>/ になります。発行者 URL は、トークンの iss クレームに含まれるとおり正確に登録してください。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 のウィザードは両方を設定します）。意図したよりも多くの ID に一致してしまうワイルドカードや部分的な GUID の subject_prefix は決して使用しないでください。
  • 多層防御として tid を固定する: 発行者 URL がすでにテナントを固定していますが、claims.tid を追加することで、後で発行者レコードが編集された場合の構成ドリフトを防げます。
  • オーディエンスを固定する: audience にデコードしたトークンの aud 値をそのまま設定し、他のアプリケーション向けに発行されたトークンが拒否されるようにします。
  • マネージド ID ごとに個別のルールを使用する: 複数の ID を認可する 1 つのルールではなく、ID ごとに 1 つのルールを作成してください。そうすることで、他に影響を与えずに単一のワークロードのアクセスを取り消せます。

次のステップ

Was this page helpful?