OktaでWIFを使用する

Oktaは、OAuth 2.0のclient_credentialsグラントを通じてサービスアプリケーションにOIDCアクセストークンを発行することで、ワークロードアイデンティティプロバイダーとして機能できます。ワークロードはOktaに対して認証を行い（通常はprivate_key_jwtを使用するため、共有シークレットは保存されません）、署名付きの「JSON Web Token」（JSONウェブトークン）、すなわち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管理コンソールで、タイプがAPI Services（OIDC、マシン間通信）の新しいアプリ統合を作成します。生成されたClient IDをメモしておきます。
2. クライアント認証を設定します。 キーレスセットアップの場合は、Public key / Private key（private_key_jwt）を選択し、ワークロードの公開JWKを登録します。または、環境で安全に保存できる場合はクライアントシークレットを使用します。以下の例では、アプリケーションのDPoP要件を無効にする必要がある場合があります。本番環境のセットアップが組織のセキュリティ要件に準拠していることを確認してください。
3. オーディエンスを設定します。 カスタム認可サーバーで、オーディエンスをhttps://api.anthropic.comに設定し、発行されるアクセストークンがそのaudクレームを持つようにします。Anthropicはこの固定値に対してaudを検証します。
4. スコープを付与します。 カスタム認可サーバーで、サービスアプリがリクエストできるスコープが少なくとも1つ存在することを確認します（例：anthropic.access）。Oktaは、付与されたスコープを含まないclient_credentialsリクエストを拒否します。
5. アクセスポリシーを作成します。 カスタム認可サーバーで、手順4で付与したスコープをサービスアプリがリクエストできるようにするルールを少なくとも1つ含むアクセスポリシーを作成します。
6. （オプション）カスタムクレームを追加します。 クライアントID以外のものでマッチングしたい場合は、認可サーバーのClaimsタブでアクセストークンにクレームを追加します。

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

Anthropicを設定する

セットアップウォークスルーに従って、Claude Consoleでフェデレーション発行者を登録し、Anthropicサービスアカウントを作成し、フェデレーションルールを作成します。以下のOkta固有の値を使用してください。

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

{
  "name": "okta-prod",
  "issuer_url": "https://acme.okta.com/oauth2/aus1a2b3c4d5e6f7g8h9",
  "jwks_source": "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に渡す必要があります。

import os
import httpx
import anthropic
from anthropic import WorkloadIdentityCredentials


def fetch_okta_token() -> str:
    response = httpx.post(
        f"{os.environ['OKTA_ISSUER']}/v1/token",
        data={
            "grant_type": "client_credentials",
            "scope": "anthropic.access",
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            # OktaアプリのプライベートキーでサインされたRFC 7523 client_assertion JWTを構築します
            "client_assertion": build_signed_client_assertion(),
        },
    )
    response.raise_for_status()
    return response.json()["access_token"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_okta_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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(message.content[0].text)

各SDKタブは呼び出し可能なパターンを示しています。Anthropic SDKは、Anthropicアクセストークンの有効期限が近づくたびにアイデンティティトークンプロバイダーを再度呼び出すため、Oktaフェッチャーは1つのトークンを無期限にキャッシュするのではなく、呼び出しごとに新しいトークンを返す必要があります。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リファレンスを参照してください。