OktaでWIFを使用する

Oktaは、OAuth 2.0のclient_credentialsグラントを通じてサービスアプリケーションにOIDCアクセストークンを発行することで、ワークロードアイデンティティプロバイダーとして機能できます。ワークロードはOktaに対して認証を行い（通常はprivate_key_jwtを使用するため、共有シークレットは保存されません）、署名された「JSON Web Token」（JWT）を受け取り、そのJWTをAnthropicと交換して短期間有効なアクセストークンを取得します。

Okta認可サーバーの発行者URLはhttps://<your-domain>.okta.com/oauth2/<auth-server-id>という形式です。組み込みのデフォルトサーバーを使用する場合、パスは/oauth2/defaultになります。

Oktaの設定と認証には、このドキュメントの範囲外となる多くの方法があります。設定と認証のメカニズムが、お客様の会社のガイダンスとセキュリティプラクティスに従っていることを確認してください。



前提条件

• WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
• API Access Managementが有効になっているOkta組織（カスタム認可サーバーに必要）。
• お客様のAnthropic組織のClaude Consoleで、サービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。
• Oktaの/v1/tokenエンドポイントからトークンをリクエストでき、api.anthropic.comに到達できるワークロード。



Oktaを設定する

大まかには、次のことを行う必要があります。

1. Oktaサービスアプリケーションを作成します。
2. デフォルトの認可サーバーを設定する（または新しいカスタム認可サーバーを作成する）際に、オーディエンス、スコープ、アクセスポリシー、およびマッチングに使用したい任意のカスタムクレームを設定します。

正確なナビゲーションは、Okta組織の設定と管理コンソールのバージョンによって異なります。以下の番号付きの手順は、一般的な方法の1つを説明しています。

1. サービスアプリ統合を作成します。 Okta Admin Consoleで、API Services（OIDC、マシン間通信）タイプの新しいアプリ統合を作成します。生成されたClient IDをメモしておきます。
2. クライアント認証を設定します。 キーレス構成の場合は、Public key / Private key（private_key_jwt）を選択し、ワークロードの公開JWKを登録します。あるいは、環境が安全に保存できる場合はクライアントシークレットを使用します。以下の例では、アプリケーションでDPoP要件を無効にする必要がある場合があります。本番環境の構成が組織のセキュリティ要件に準拠していることを確認してください。
3. オーディエンスを設定します。 カスタム認可サーバーで、発行されるアクセストークンがそのaudクレームを持つように、オーディエンスをhttps://api.anthropic.comに設定します。Anthropicはこの固定値に対してaudを検証します。
4. スコープを付与します。 カスタム認可サーバーで、サービスアプリがリクエストを許可されているスコープが少なくとも1つ存在することを確認します（例：anthropic.access）。Oktaは、付与されたスコープを含まないclient_credentialsリクエストを拒否します。
5. カスタム認可サーバーで、手順4で付与したスコープをサービスアプリがリクエストできるようにするルールを少なくとも1つ含むアクセスポリシーを作成します。

client_credentialsを使用するサービスアプリの場合、Oktaは発行されたアクセストークンのsubクレームをアプリケーションのClient IDに、issを認可サーバーの発行者URLに設定します。



Anthropicを設定する

Claude Consoleで、Settings → Workload identityを開き、Connect workloadをクリックして、Custom OIDCを選択します。ウィザードが、発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を順を追って案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

フェデレーション発行者: Oktaカスタム認可サーバーのURLとディスカバリーモードを使用します。AnthropicはOktaの.well-known/openid-configurationディスカバリードキュメントを読み取り、そこで公開されているjwks_uriからJWKSを取得します。

{
  "name": "okta-prod",
  "issuer_url": "https://acme.okta.com/oauth2/aus1a2b3c4d5e6f7g8h9",
  "jwks": { "type": "discovery" }
}

フェデレーションルール: Oktaのsubクレーム（サービスアプリのClient ID）でマッチングします。Oktaでカスタムクレームを定義した場合は、代わりにclaimsマップまたはCELのconditionを使用してそれらでマッチングできます。

{
  "name": "okta-pipeline",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "0oa1b2c3d4e5f6g7h8i9",
    "audience": "https://api.anthropic.com"
  },
  "target": { "type": "service_account", "service_account_id": "svac_..." },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}



トークンを取得してClaude APIを呼び出す

ワークロードのランタイム内でトークンを利用可能にする（投影されたファイルまたはローカルメタデータエンドポイントを通じて）プラットフォームネイティブのプロバイダー（AWS、Google Cloud、Kubernetes）とは異なり、Oktaはそれを行いません。ワークロードはOktaのトークンエンドポイントを呼び出してJWTを取得し、そのJWTをアイデンティティトークンとしてAnthropic SDKに渡す必要があります。

各SDKタブは呼び出し可能なパターンを示しています。Anthropic SDKは、Anthropicアクセストークンの有効期限が近づくたびにアイデンティティトークンプロバイダーを再度呼び出すため、Oktaフェッチャーはトークンを無期限にキャッシュするのではなく、呼び出しごとに新しいトークンを返す必要があります。ant CLIは交換ごとにANTHROPIC_IDENTITY_TOKEN_FILEを再読み込みするため、長時間実行されるシェルではタイマーでそのファイルを更新してください。



セットアップを検証する

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。400 invalid_grantが発生した場合は、失敗した交換のトラブルシューティングを参照してください。Okta側で最も一般的な原因はissuer_urlの不一致です（/oauth2/<auth-server-id>パスを含める必要があります。Okta組織認可サーバーは使用できません）。



ルールのスコープを設定する

ルールのmatchブロックを、ユースケースに適合する最も狭いスコープにロックしてください。

• 正確なClient IDを固定する: subject_prefixを、末尾に*を付けずにサービスアプリの完全なClient IDに設定します。
• オーディエンスを固定する: 認可サーバーで設定したaudience値にマッチさせることで、異なるオーディエンス向けに発行されたトークンが拒否されるようにします。
• カスタムクレームでマッチングする: よりきめ細かいスコープ設定のために、認可サーバーのClaimsタブでクレームを追加し、ルールのclaimsマップまたはCELのconditionでマッチングします。
• サービスアプリごとに1つのルールを使用する: 複数のアプリで1つのルールを共有するのではなく、サービスアプリごとに個別のフェデレーションルールを作成します。



次のステップ

• 完全な認証情報の解決順序とプロファイル設定については、WIFリファレンスを確認してください。
• CEL式を使用してOktaのカスタムクレームでマッチングする方法については、WIFリファレンスを参照してください。