> ## Documentation Index > Fetch the complete documentation index at: https://wb-21fd5541-feat-cli-docs-generator.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # SDK でフェデレーテッドアイデンティティを使用する W\&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W\&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW\&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW\&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。 [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)は、SDKを使用したアイデンティティ連携の基盤を形成しています。 アイデンティティ連携は、すべてのプラットフォームタイプの `Enterprise` プランで `Preview` として利用可能です - SaaS Cloud、Dedicated Cloud、およびセルフマネージドインスタンス。ご質問がある場合は、W\&Bチームにお問い合わせください。 このドキュメントの目的のために、`identity provider` と `JWT issuer` という用語は交換可能に使われています。この機能のコンテキストでは、両方とも同じものを指します。 ## JWTイシュア設定 最初のステップとして、組織管理者はW\&B組織とアクセス可能なJWTイシュアの間で連携を設定しなければなりません。 * 組織ダッシュボードの **Settings** タブに移動します。 * **Authentication** オプションで `Set up JWT Issuer` をクリックします。 * テキストボックスにJWTイシュアのURLを追加し、`Create` を押します。 W\&Bは、`${ISSUER_URL}/.well-known/openid-configuration` パスでOIDCディスカバリードキュメントを自動的に探し、ディスカバリードキュメント内の関連URLでJSON Web Key Set (JWKS) を見つけようとします。JWKSは、JWTが関連するアイデンティティプロバイダーによって発行されたものであることを確認するために使用されるリアルタイム検証に利用されます。 ## W\&BへのJWTを使用 JWTイシュアがW\&B組織のために設定されると、ユーザーはそのアイデンティティプロバイダーによって発行されたJWTを使用して関連するW\&B Projectsへのアクセスを開始できます。JWTを使用するメカニズムは次の通りです： * 組織内で利用可能なメカニズムの1つを使用して、アイデンティティプロバイダーにサインインする必要があります。一部のプロバイダーはAPIやSDKを使用して自動化された方法でアクセスでき、他のプロバイダーは関連するUIを使用してのみアクセス可能です。詳細については、W\&B組織管理者やJWTイシュアの所有者にお問い合わせください。 * アイデンティティプロバイダーにサインインした後、JWTをセキュアな場所に保存し、環境変数 `WANDB_IDENTITY_TOKEN_FILE` に絶対ファイルパスを設定してください。 * W\&B SDKやCLIを使用してW\&Bプロジェクトにアクセスします。SDKやCLIは自動的にJWTを検出し、JWTが正常に検証された後にそれをW\&Bアクセストークンと交換します。W\&Bアクセストークンは、AIワークフローを有効にするためにrun、メトリクス、アーティファクトのログを記録するための関連するAPIにアクセスするために使用されます。アクセストークンはデフォルトで `~/.config/wandb/credentials.json` のパスに保存されます。環境変数 `WANDB_CREDENTIALS_FILE` を指定することでそのパスを変更することができます。 JWTは、APIキー、パスワードなどの長期間の資格情報の欠点に対処するための短期間の資格情報として意図されています。あなたのアイデンティティプロバイダーで設定されたJWTの有効期限に応じて、JWTを継続的にリフレッシュし、環境変数 `WANDB_IDENTITY_TOKEN_FILE` で参照されるファイルに保存されていることを確認する必要があります。 W\&Bアクセストークンにもデフォルトの有効期限があり、SDKまたはCLIは、それがあなたのJWTを使用して自動的にリフレッシュしようとします。その時点でユーザーJWTが期限切れになってリフレッシュされていない場合、認証に失敗する可能性があります。可能であれば、W\&B SDKやCLIを使用したAIワークロードの一部として、JWTの取得と有効期限後のリフレッシュメカニズムを実装するべきです。 ### JWT検証 JWTをW\&Bアクセストークンと交換し、プロジェクトにアクセスするためのワークフローの一環として、JWTは以下の検証を受けます： * JWT署名はW\&B組織レベルでJWKSを使用して検証されます。これが最初の防御線であり、これが失敗した場合、あなたのJWKSやJWTの署名に問題があることを意味します。 * JWT内の `iss` クレームは、組織レベルで設定されたイシュアURLと等しいものである必要があります。 * JWT内の `sub` クレームは、W\&B組織で設定されたユーザーのメールアドレスと等しいものである必要があります。 * JWT内の `aud` クレームは、AIワークフローの一部としてアクセスしているプロジェクトを保有しているW\&B組織の名前と同じである必要があります。[Dedicated Cloud](/ja/platform/hosting/hosting-options/dedicated_cloud) または [セルフマネージド](/ja/platform/hosting/hosting-options/self-managed) インスタンスの場合、インスタンスレベルの環境変数 `SKIP_AUDIENCE_VALIDATION` を `true` に設定してオーディエンスクレームの検証をスキップするか、`wandb` をオーディエンスとして使用します。 * JWT内の `exp` クレームは、トークンが有効で期限が切れていないか、リフレッシュが必要であるかを確認するためにチェックされます。 ## 外部サービスアカウント W\&Bは長期間のAPIキーを持つ組み込みのサービスアカウントを長年にわたりサポートしてきました。SDKとCLIのアイデンティティ連携機能を使用すると、外部サービスアカウントを持ち込むことができ、JWTを使用して認証することも可能です。ただし、それらが組織レベルで設定されている同じイシュアによって発行されている限りです。チーム管理者は、組み込みのサービスアカウントのように、チームの範囲内で外部サービスアカウントを設定することができます。 外部サービスアカウントを設定するには： * チームの **Service Accounts** タブに移動します。 * `New service account` を押します。 * サービスアカウントの名前を入力し、`Authentication Method` として `Federated Identity` を選択し、`Subject` を提供して `Create` を押します。 外部サービスアカウントのJWT内の `sub` クレームは、チーム管理者がチームレベルの **Service Accounts** タブでそのサブジェクトとして設定したものと同じである必要があります。このクレームは、[JWT検証](#jwt-validation) の一環として検証されます。`aud` クレームの要件は、人間のユーザーJWTと同様です。 [W\&Bへの外部サービスアカウントのJWTを使用するとき](#using-the-jwt-to-access-wb)、通常、初期JWTを生成し、継続的にリフレッシュするワークフローを自動化する方が簡単です。外部サービスアカウントを使用してログに記録されたrunを人間ユーザーに帰属させる場合、組み込みサービスアカウントと同様に、AIワークフローのために環境変数 `WANDB_USERNAME` または `WANDB_USER_EMAIL` を設定することができます。 W\&Bは、データの機密性が異なるAIワークロード全体で、柔軟性と簡潔さのバランスを取るために、組み込みおよび外部サービスアカウントの組み合わせを使用することをお勧めします。