Workload Identity Federation

「Workload Identity Federation」（ワークロードIDフェデレーション）、すなわちWIFを使用すると、ワークロードは長期間有効なsk-ant-...形式のAPIキーの代わりに、短期間有効な「OpenID Connect」（OIDC）トークンでClaude APIに対して認証できます。トークンは、すでに運用しているIDプロバイダー（IdP）から発行されます。AWS IAM、Google Cloud、またはGitHub Actions、Kubernetes、SPIFFE、Microsoft Entra ID、Oktaなどの標準準拠のOIDC発行者が利用できます。

ワークロードは、IDプロバイダーから署名されたJWTを提示します。Anthropicは、Claude Consoleで設定した信頼ルールに照らしてそれを検証し、組織内のサービスアカウントにバインドされた短期間有効なAnthropicアクセストークンを返します。発行、CIへの保存、ローテーション、漏洩の心配が必要な静的シークレットは存在しません。

Workload Identity Federationは、無期限ではなく数分で有効期限が切れるトークンで静的APIキーを置き換えることにより、セキュリティ体制を強化します。ただし、これだけで完全なセキュリティが実現されるわけではありません。フェデレーション認証の強度は、JWTに署名する上流のIDプロバイダーの強度に依存します。多層防御のために、Workload Identity FederationをIdPがすでにサポートしている制御（ワークロードIDバインディング、条件付きアクセス、監査ログ）と組み合わせてください。



概念

ワークロードがフェデレーションを行う前に、Claude Consoleで3つのリソースを設定します。これらを組み合わせることで、「発行者Xによって署名され、Yのようなクレームを持つトークンは、サービスアカウントZとして動作できる」という関係を表現します。



サービスアカウント

サービスアカウント（svac_...）は、Anthropic組織内の名前付きの非人間IDです。これは、フェデレーショントークンが代理として動作するプリンシパルです。サービスアカウントは組織レベルに存在し、ワークスペースのメンバーとして追加されるとそのワークスペースでアクティブになります。トークン交換時に、Anthropicはフェデレーションルールのワークスペースがサービスアカウントのワークスペースメンバーシップのいずれかと一致することを確認します。発行されたトークンは、APIキーと同様に、そのワークスペースのレート制限と使用量の帰属に従います。人間のユーザーとは異なり、サービスアカウントにはメールアドレス、パスワード、Consoleログインがありません。すべてのサービスアカウントは暗黙的に組織のデフォルトワークスペースのメンバーです。他のワークスペースで動作させる必要がある場合は、明示的なメンバーシップを追加してください。

APIキーとの主な違いは、APIキーはそれ自体が認証情報であるのに対し、サービスアカウントはオンデマンドで認証情報が発行される対象であるという点です。どのワークロードがどのサービスアカウントとして動作したかを監査できます。



フェデレーション発行者

フェデレーション発行者（fdis_...）は、OIDC IDプロバイダーを組織に登録します。発行者を登録することで、「このプロバイダーによって署名されたJWTは、自分の組織のワークロードIDをアサートできる」とAnthropicに伝えます。

発行者には2つの設定項目があります。

• 発行者URL： プロバイダーのJWTに表示される正確なissクレーム値です。例えば、https://token.actions.githubusercontent.comやhttps://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLEなどです。
• JWKSソース： AnthropicがJWT署名を検証するための公開鍵を取得する方法です。発行者URLで/.well-known/openid-configurationを提供するプロバイダーにはdiscovery（デフォルト）を使用します。JWKSエンドポイントを直接指定するにはexplicit_urlを使用し、パブリックインターネットから到達できない発行者（プライベートKubernetesクラスターなど）の場合はinlineを使用してキーセットをアップロードします。

発行者URLとJWKS URLはhttpsで、ポート443を使用し、パブリックIPアドレスに解決されるパブリックDNSホスト名を使用する必要があります。IPリテラルは受け付けられません。これらの制約はAnthropicが取得するURLにのみ適用されます。explicit_urlモードとinlineモードでは、issuer_urlは文字列として比較されるため、内部ホスト名を参照できます。

通常、環境ごとに1つの発行者を登録します。本番EKSクラスター、ステージングクラスター、GitHub Actionsは3つの別々の発行者です。



フェデレーションルール

フェデレーションルール（fdrl_...）は、発行者とサービスアカウントの間の橋渡しです。「発行者XからのJWTがYのようなクレームを持つ場合、スコープSでサービスアカウントZのトークンを発行する」という関係を定義します。

ルールは、マッチ条件、ターゲット、およびルールがマッチした場合に適用される認可スコープとトークンの有効期間を定義します。

• マッチ： 受信JWTが満たす必要がある条件です。subject_prefix（例えばsystem:serviceaccount:prod:worker、または末尾に*を付けたプレフィックスマッチ）、正確なaudience、正確なクレーム値のマップ、複雑なロジック用のCEL condition式、またはこれらの任意の組み合わせでマッチできます。subject_prefix、claims、conditionのうち少なくとも1つを設定する必要があり、JWTが受け入れられるには設定されたすべてのマッチャーが合格する必要があります。
• ターゲット： マッチしたJWTがマッピングされるサービスアカウントです。
• 認可： 発行されたトークンに付与されるOAuth scopeです。デフォルトはworkspace:developerで、そのワークスペース用に発行されたAPIキーと同じアクセス権を付与します。一部の製品では、そのフローからルールを作成するときにスコープがロックされます。例えば、MCPトンネルのトンネル作成モーダルは、workspace:manage_tunnelsにスコープされたルールを作成します。OAuthスコープを参照してください。ルールはtoken_lifetime_seconds（60〜86400、デフォルト3600）も設定します。

1つの発行者に多数のルールを設定できます。チーム、名前空間、または権限レベルごとに1つずつです。ルールはIDによって評価されます。クライアントは交換リクエストで使用するルールを指定し、AnthropicはJWTがそのルールのマッチ条件を満たしていることを検証します。暗黙的なルール検索はありません。



仕組み

1. IdPがワークロードにJWTを発行します。 ほとんどのプラットフォームでは、これは環境に組み込まれています。Kubernetesのプロジェクテッドサービスアカウントトークン、Google Cloudメタデータサーバー、Azure IMDS、またはGitHub Actions OIDCエンドポイントなどです。JWTのissクレームはプロバイダーを識別し、subおよびその他のクレームは特定のワークロードを識別します。
2. SDKがJWTをAnthropicアクセストークンと交換します。 SDKはRFC 7523のjwt-bearerグラントを使用して、JWTをPOST /v1/oauth/tokenに送信します。Anthropicは発行者のJWKSとフェデレーションルールのマッチ条件に照らしてJWTを検証し、ルールのターゲットサービスアカウントに代わって動作する短期間有効なsk-ant-oat01-...トークンを返します。
3. SDKはすべてのリクエストでトークンを送信し、有効期限が切れる前に更新します。 アプリケーションコードはapi_keyなしでクライアントを構築し、通常どおりAPIを呼び出します。SDKはトークンの有効期限が切れる前に交換を再実行します。



フェデレーションの設定

Anthropic組織でadmin、owner、またはprimary ownerロールが必要です。また、到達可能なJWKSエンドポイントを持つOIDC対応IDプロバイダー（またはエアギャップクラスターの場合は貼り付け可能なJWKSドキュメント）、およびそのプロバイダーからIDトークンを取得できるワークロードが必要です。

Connect workloadウィザードは、3つのリソース（発行者、サービスアカウント、フェデレーションルール）すべてを1つのガイド付きフローで作成し、接続をエンドツーエンドで検証します。

これらのリソースをプログラムで管理するには、curlによるウォークスルーについてAdmin APIでWIFを管理するを参照するか、完全なパラメータの詳細とレスポンススキーマについてサービスアカウントAPIリファレンス、フェデレーション発行者APIリファレンス、フェデレーションルールAPIリファレンスを参照してください。



ワークロードからの認証

フェデレーションが設定されると、ワークロードは実行時にIdPが発行したJWTをAnthropicトークンと交換します。SDKが交換と更新ループを処理します。cURLタブは、シェルスクリプト、デバッグ、またはSDKサポートのない言語向けに、基盤となるHTTP交換を示しています。



SDKクライアントの構築

クライアントは、明示的な認証情報を指定して構築することも、引数なしで構築することもできます。引数なしの場合、SDKは認証情報の優先順位で説明されているように、環境変数またはアクティブなプロファイルから認証情報を解決します。引数なしの形式は、本番ワークロードに推奨されるパターンです。同じコンテナイメージをどこにでもデプロイし、環境ごとにANTHROPIC_FEDERATION_RULE_ID、ANTHROPIC_ORGANIZATION_ID、ANTHROPIC_SERVICE_ACCOUNT_ID、ANTHROPIC_WORKSPACE_ID、ANTHROPIC_IDENTITY_TOKEN_FILEを注入します。

from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile

client = Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile(
            "/var/run/secrets/anthropic.com/token"
        ),
        federation_rule_id="fdrl_...",
        organization_id="00000000-0000-0000-0000-000000000000",
        service_account_id="svac_...",
        workspace_id="wrkspc_...",
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(message.content[0].text)

トークン交換レスポンスはRFC 6749 §5.1に従います。フィールドリファレンスについては、トークン交換レスポンスを参照してください。



認証情報の優先順位

すべてのSDKは、同じ5段階の順序で認証情報を解決します。コンストラクタ引数、次にANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN、次に明示的なANTHROPIC_PROFILE、次にフェデレーション環境変数、最後に暗黙的なアクティブプロファイルです。認証情報を生成する最初のソースが採用されます。

完全な優先順位テーブル、各層のセマンティクス、およびプロファイルファイルスキーマについては、WIFリファレンスの認証情報の優先順位を参照してください。



APIキーからの移行

既存のワークロードをダウンタイムなしで静的APIキーからフェデレーションに切り替えるには、次の手順を実行します。

1. フェデレーションを並行して設定します。 設定ウォークスルーを完了し、フェデレーションルールがワークロードのトークンとマッチすることを確認します。現時点では既存のANTHROPIC_API_KEYをそのままにしておきます。
2. どの認証情報が採用されるかをスモークテストします。 ワークロード内からant auth statusを実行します（またはSDKデバッグログを確認します）。ANTHROPIC_API_KEYは優先順位チェーンでフェデレーション層よりも上位にあるため、この段階ではまだAPIキーが採用されます。
3. 注入されているすべての場所でANTHROPIC_API_KEYを設定解除します。 CIシークレット、コンテナ環境、シェルプロファイルから削除します（前述の警告を参照）。ant auth statusを再実行し、フェデレーションソースが選択されていることを確認します。
4. APIキーを失効させます。 ワークロードがフェデレーショントークンで実行されるようになったら、Claude ConsoleのSettings → API keysでキーを削除します。



トークンの有効期間と更新

発行されたAnthropicトークンの有効期間は、（a）ルールのtoken_lifetime_seconds（デフォルト3600秒）と（b）提示したIdP JWTの残り有効期間の2倍のうち、小さい方です。結果は60秒未満になることはありません。2番目の制約により、Anthropicトークンが派生元の上流IDよりもわずかなマージンを超えて長く存続することを防ぎます。

SDKはトークンをキャッシュし、botocoreをモデルにした2段階のスケジュールで更新します。

• アドバイザリ更新は有効期限の120秒前です。SDKは新しい交換を試みます。トークンエンドポイントに到達できない場合、SDKはキャッシュされたトークンを引き続き提供します。このトークンはまだ約90秒間有効です。
• 必須更新は有効期限の30秒前です。この時点で交換が失敗するとエラーが発生します。キャッシュされたトークンは有効期限に近すぎて安全ではありません。

SDKは交換のたびにANTHROPIC_IDENTITY_TOKEN_FILEを再読み込みするため、ローテーションされたプロジェクテッドトークン（例えば、Kubernetesサービスアカウントトークンはexpよりもかなり前にローテーションされます）を透過的に取得します。



IDプロバイダー

各ガイドでは、そのプラットフォームでJWTがどこから来るか、そのクレームがどのようなものか、登録する発行者とルールの設定について説明しています。



関連項目

• Admin APIでWIFを管理する：Infrastructure as Codeから発行者、サービスアカウント、ルールを作成する
• WIFリファレンス：環境変数、プロファイルファイルスキーマ、検証ルール、エラーコード
• 認証：Anthropic SDK全体のすべての認証オプション
• Admin APIリファレンス：すべてのAdmin APIエンドポイントの生成されたリクエストおよびレスポンススキーマ