Claude Platform Docs
管理IDプロバイダー

OktaでWIFを使用する

Workload Identity Federationを使用して、OktaサービスアプリケーションのIDをClaude APIにフェデレーションします。

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

Okta認可サーバーの発行者（issuer）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. オーディエンスを設定する。 カスタム認可サーバーで、オーディエンスを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で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をIDトークンとしてAnthropic SDKに渡す必要があります。

import os
import httpx2
import anthropic
from anthropic import WorkloadIdentityCredentials


def fetch_okta_token() -> str:
    response = httpx2.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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "text"))

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

セットアップを検証する

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。交換が不透明な401 authentication_errorレスポンス（メッセージAuthentication failed）で失敗した場合は、認証履歴ページで拒否理由を確認し、失敗した交換のトラブルシューティングを参照してください。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リファレンスを参照してください。

Was this page helpful?