> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # SDK でフェデレーションされたアイデンティティを使用する > JSON Web Token (JWT) を用いたアイデンティティ フェデレーションにより、APIキーを使わずに W&B SDK と CLI で認証します。 アイデンティティ フェデレーションを使用すると、有効期間の長いAPIキーの代わりに、組織の認証情報で W\&B SDK と CLI にサインインできます。W\&B の組織管理者が組織に SSO を設定している場合、W\&B アプリ UI へのサインインにはすでにその認証情報を使用しているはずです。アイデンティティ フェデレーションは W\&B SDK 向けの SSO のようなものですが、JSON Web Token (JWT) を直接使用する点が異なります。APIキーの代替手段として、アイデンティティ フェデレーションを使用してください。 このページは、W\&B 組織の JWT issuer を設定する組織管理者と、JWT を使用して W\&B で認証するユーザーおよびサービスアカウントを対象としています。 SDK でのアイデンティティ フェデレーションは、[RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) に基づいています。 アイデンティティ フェデレーションは、Multi-tenant Cloud、専用クラウド、セルフマネージドでプレビューとして利用できます。利用には [Enterprise ライセンス](/ja/products/wandb/platform/hosting/enterprise-licenses)が必須です。詳細やサポートについては、担当の AISE または[サポート](mailto:forge-support@coreweave.com)にお問い合わせください。 このドキュメントでは、「アイデンティティプロバイダ」と「JWT issuer」を同じ意味で使用しています。この機能においては、どちらも同じものを指します。

JWT issuer を設定する

ユーザーが JWT で認証できるようにするには、事前に組織管理者が W\&B 組織と一般公開されている JWT issuer との間でフェデレーションを設定する必要があります。 1. 組織のダッシュボードで **Settings** タブにアクセスします。 2. **Authentication** オプションで、**Set up JWT Issuer** をクリックします。 3. テキストボックスに JWT issuer の URL を入力し、**Create** をクリックします。 W\&B は、`${ISSUER_URL}/.well-known/openid-configuration` のパスにある OIDC ディスカバリードキュメントを自動的に検索します。次に、ディスカバリードキュメントを基に、該当する URL にある JSON Web Key Set (JWKS) を特定します。W\&B は JWKS を使用して JWT をリアルタイムで検証し、該当するアイデンティティプロバイダによって発行されたものであることを確認します。 この手順が完了すると、W\&B 組織は JWT issuer とフェデレーションされます。以降、組織内のユーザーは、そのプロバイダーが発行した JWT を使用して W\&B で認証できるようになります。

JWT を使用して W\&B にアクセスする

組織管理者が JWT issuer を設定すると、ユーザーはそのアイデンティティプロバイダが発行した JWT を使用して W\&B プロジェクトにアクセスできるようになります。JWT の使用方法は次のとおりです。 1. 組織で利用可能な方法のいずれかで、アイデンティティプロバイダにサインインします。プロバイダーによっては API や SDK を使用して自動的にアクセスできますが、該当する UI からしかアクセスできないものもあります。詳細については、W\&B の組織管理者または JWT issuer の所有者にお問い合わせください。 2. アイデンティティプロバイダにサインインして JWT を取得したら、安全な場所にあるファイルに保存します。そのファイルの絶対パスを環境変数 `WANDB_IDENTITY_TOKEN_FILE` に設定します。 3. W\&B SDK または CLI を使用して W\&B プロジェクトにアクセスします。SDK または CLI は JWT を自動的に検出し、検証したうえで W\&B アクセストークンと交換します。W\&B アクセストークンを使用すると、run、メトリクス、アーティファクトのログなど、AI ワークフローに必要な API にアクセスできます。デフォルトでは、アクセストークンは `~/.config/wandb/credentials.json` に保存されます。このパスは、環境変数 `WANDB_CREDENTIALS_FILE` を指定して変更できます。 JWT は有効期間の短い認証情報であり、APIキーやパスワードなど有効期間の長い認証情報の欠点を補います。JWT の有効期限は、アイデンティティプロバイダの設定によって異なります。JWT は有効期限が切れる前に更新し、環境変数 `WANDB_IDENTITY_TOKEN_FILE` で参照されるファイルに保存してください。 W\&B アクセストークンにもデフォルトの有効期間があり、期限が切れると SDK または CLI は JWT を使用してトークンの更新を試みます。その時点でユーザーの JWT も期限切れのまま更新されていない場合、認証は失敗します。可能であれば、JWT の取得と有効期限切れ後の更新の仕組みを、W\&B SDK または CLI を使用する AI ワークロードに組み込んでください。

JWT の検証

有効なトークンにのみアクセスを許可するため、JWT に対して次の検証が行われます。これらの検証は、SDK または CLI が JWT を W\&B アクセストークンと交換し、project にアクセスする際に実行されます。 * W\&B は、W\&B 組織レベルの JWKS を使用して JWT の署名を検証します。これは最初の防御線です。この検証が失敗した場合は、JWKS または JWT の署名方法に問題があります。 * JWT の `iss` クレームは、組織レベルで設定された発行者 URL と一致している必要があります。 * JWT の `sub` クレームは、W\&B 組織で設定されているユーザーのメールアドレスと一致している必要があります。 * JWT の `aud` クレームは、AI ワークフローでアクセスする project が属する W\&B 組織の名前と一致している必要があります。 [専用クラウド](/ja/products/wandb/platform/hosting/hosting-options/dedicated-cloud) または [セルフマネージド](/ja/products/wandb/platform/hosting/hosting-options/self-managed) インスタンスの場合: * オーディエンスの検証をスキップするには、環境変数 `FEDERATED_AUTH_AUDIENCES` を `wandb` に設定します。 * 組織によっては、オーディエンスに固有の要件がある場合があります。`aud` の値をカスタマイズするには、環境変数 `FEDERATED_AUTH_AUDIENCES` に、オーディエンスの値をカンマ区切りで列挙した文字列を設定します。 * W\&B は JWT の `exp` クレームを確認し、トークンが有効か、有効期限切れで更新が必要かを判断します。

外部サービスアカウント

W\&B では以前から、有効期間の長い APIキーを持つ組み込みのサービスアカウントをサポートしてきました。SDK と CLI 向けのアイデンティティ フェデレーションを使用すると、認証に JWT を使用する外部サービスアカウントも利用できます。これらの JWT は、組織で設定された発行者が発行したものである必要があります。チーム管理者は、組み込みのサービスアカウントと同様に、チームのスコープ内で外部サービスアカウントを設定できます。 外部サービスアカウントを設定するには、チーム管理者が次の手順を実行します。 1. チームの **Service Accounts** タブにアクセスします。 2. **New service account** をクリックします。 3. サービスアカウントの名前を入力します。 4. **Authentication Method** として **Federated Identity** を選択し、**Subject** を入力します。詳しくは、[アイデンティティプロバイダの Subject 値を決定する](#determine-the-subject-value-for-your-identity-provider)を参照してください。 5. **Create** をクリックします。 これで外部サービスアカウントがチームに登録され、設定済みのアイデンティティプロバイダが発行した JWT を使用して W\&B にアクセスできるようになります。外部サービスアカウントの JWT に含まれる `sub` クレームは、チーム管理者がチームレベルの **Service Accounts** タブで設定した Subject と一致している必要があります。W\&B は、[JWT の検証](#jwt-validation)の一環としてこのクレームを確認します。`aud` クレームの要件は、人間のユーザーの JWT と同様です。 [外部サービスアカウントの JWT を使用して W\&B にアクセスする](#use-the-jwt-to-access-wb)場合は、ワークフローを自動化すると多くの場合効率的です。オートメーションによって初回の JWT が生成され、必要に応じて更新されます。外部サービスアカウントでログした run を人間のユーザーに関連付けるには、組み込みのサービスアカウントと同様に、AI ワークフローで環境変数 `WANDB_USERNAME` または `WANDB_USER_EMAIL` を設定します。 W\&B では、データの機密度が異なる AI ワークロード全体で、組み込みのサービスアカウントと外部サービスアカウントを組み合わせて使用することを推奨しています。両者を組み合わせることで、柔軟性とシンプルさを両立できます。

アイデンティティプロバイダの Subject の値を確認する

**Subject** に入力する値は、IdP がサービスアカウント向けに発行する JWT の `sub` (subject) クレームと完全に一致している必要があります。W\&B は、どのアイデンティティプロバイダに対しても同じ方法で比較します。照合は完全一致で、大文字と小文字、および空白が区別されます。そのため、末尾にスペースが 1 つあったり、大文字と小文字が違っていたりするだけで認証に失敗します。 **Subject** の値は IdP に完全に依存するため、W\&B アプリは空でない **Subject** であれば、値を検証せずに受け入れます。サービスアカウントの作成時点では、W\&B は誤った値を検出できません。値が誤っている場合は、後でサービスアカウントが JWT を提示した時点で認証に失敗します。 正しい値を確認する最も確実な方法は、実際のトークンから読み取ることです。サービスアカウント向けに発行されたサンプルの JWT を取得し、そのペイロード (2 つのドットに挟まれた中央のセグメント) をローカルで base64url デコードして、`sub` の値をそのまま **Subject** フィールドにコピーしてください。JWT は認証情報であるため、サードパーティのオンラインデコーダーには貼り付けないでください。 値はプロバイダーによって異なります。以下は一般的な例ですが、必ず実際のトークンで確認してください。 | アイデンティティプロバイダ | `sub` の値の確認場所 | | - | - | | Microsoft Entra ID | サービスプリンシパルの **Object ID** です。[Microsoft Entra 管理センター](https://entra.microsoft.com)の **Enterprise Applications** で確認できます。**App registration** の Object ID ではなく、**Enterprise Application** (サービスプリンシパル) の Object ID を使用してください。アプリ専用 (クライアント認証情報) トークンの場合、Entra ID が `sub` に設定するのは通常この値です。 | | Google Cloud (GCP) | Google がサービスアカウント向けに発行する ID トークンの `sub` の値です。 | ## Related topics - [Bring your own bucket (BYOB)](/ja/products/wandb/platform/hosting/data-security/secure-storage-connector.md)