Workload Identity Federation

「Workload Identity Federation」（ワークロードアイデンティティフェデレーション）、すなわち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プロバイダーの強度に依存します。多層防御のために、IdPがすでにサポートしている制御（ワークロードアイデンティティバインディング、条件付きアクセス、監査ログ）とWorkload Identity Federationを組み合わせてください。

概念

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

サービスアカウント

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

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

フェデレーション発行者

フェデレーション発行者（fdis_...）は、OIDC IDプロバイダーを組織に登録します。発行者を登録することで、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は、それぞれ別の発行者になります。

フェデレーションルール

フェデレーションルール（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トンネルのトンネル作成モーダルは、org: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対応のIDプロバイダー（またはエアギャップクラスターの場合は貼り付け可能なJWKSドキュメント）、およびそのプロバイダーからIDトークンを取得できるワークロードが必要です。

Claude Consoleで、Settings → Workload identityに移動します。

ワークロードからの認証

フェデレーションが設定されると、ワークロードは実行時に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トークンが、その派生元である上流のアイデンティティよりもわずかなマージンを超えて長く存続することを防ぎます。

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

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

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

IDプロバイダー

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

関連情報

• WIFリファレンス：環境変数、プロファイルファイルスキーマ、検証ルール、エラーコード
• 認証：Anthropic SDK全体のすべての認証オプション