Workload Identity Federation

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

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

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



概念

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



サービスアカウント

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

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



連携発行者

連携発行者（fdis_...）は、OIDCアイデンティティプロバイダーを組織に登録します。発行者を登録することは、Anthropicに「このプロバイダーによって署名されたJWTは、私の組織のワークロードアイデンティティを主張できる」と伝えることを意味します。

発行者には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組織の管理者、オーナー、またはプライマリオーナーのロール、到達可能なJWKSエンドポイントを持つOIDC対応のアイデンティティプロバイダー（またはエアギャップされたクラスター用に貼り付け可能なJWKSドキュメント）、そしてそのプロバイダーからアイデンティティトークンを取得できるワークロードが必要です。

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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "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（デフォルト3,600秒）と、(b) 提示したIdP JWTの残りの有効期間の2倍のうち、短い方になります。結果が60秒未満になることはありません。2番目の制限により、Anthropicトークンが、その派生元である上流のアイデンティティよりも大幅に長く存続することを防ぎます。

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

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

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



アイデンティティプロバイダー

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



関連項目

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