> ## 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.

# Utiliser des identités fédérées avec le SDK

> Utilisez la fédération d’identités avec des JSON Web Tokens (JWT) pour vous authentifier auprès du SDK et de la CLI W&B sans clé API.

Utilisez la fédération d’identités pour vous connecter au SDK et à la CLI W\&B avec les identifiants d’authentification de votre organisation, plutôt qu’avec une clé API à longue durée de vie. Si l’administrateur de votre organisation W\&B a configuré le SSO pour votre organisation, vous utilisez déjà ces identifiants pour vous connecter à l’interface de l’application W\&B. La fédération d’identités est en quelque sorte l’équivalent du SSO pour le SDK W\&B, à ceci près qu’elle utilise directement des JSON Web Tokens (JWT). Elle constitue une alternative aux clés API.

Cette page s’adresse aux administrateurs de l’organisation qui configurent l’émetteur JWT d’une organisation W\&B, ainsi qu’aux utilisateurs et aux comptes de service qui s’authentifient auprès de W\&B à l’aide de JWT.

La fédération d’identités avec le SDK repose sur la [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523).

<Note>
  La fédération d’identités est disponible en préversion pour le Cloud mutualisé, le Cloud dédié et les déploiements autogérés. Une [licence Enterprise](/fr/products/wandb/platform/hosting/enterprise-licenses) est requise. Pour en savoir plus ou obtenir de l’aide, contactez votre AISE ou l’[assistance](mailto:forge-support@coreweave.com).
</Note>

<Note>
  Ce document emploie indifféremment les termes « fournisseur d’identité » et « émetteur JWT ». Dans le contexte de cette fonctionnalité, ils désignent la même chose.
</Note>

<h2 id="set-up-the-jwt-issuer">
  Configurer l’émetteur JWT
</h2>

Avant que les utilisateurs puissent s’authentifier avec des JWT, un administrateur de l’organisation doit établir une fédération entre votre organisation W\&B et un émetteur JWT accessible publiquement.

1. Accédez à l’onglet **Settings** du tableau de bord de votre organisation.
2. Dans l’option **Authentication**, cliquez sur **Set up JWT Issuer**.
3. Saisissez l’URL de l’émetteur JWT dans la zone de texte, puis cliquez sur **Create**.

W\&B recherche automatiquement un document de découverte OIDC à l’emplacement `${ISSUER_URL}/.well-known/openid-configuration`. À partir de ce document, W\&B localise le JSON Web Key Set (JWKS) à l’URL indiquée. W\&B utilise le JWKS pour valider les JWT en temps réel et vérifier qu’ils ont bien été émis par le fournisseur d’identité concerné.

Une fois cette étape terminée, votre organisation W\&B est fédérée avec l’émetteur JWT. Les utilisateurs de votre organisation peuvent alors s’authentifier auprès de W\&B à l’aide de JWT émis par ce fournisseur.

<h2 id="use-the-jwt-to-access-wb">
  Utiliser le JWT pour accéder à W\&B
</h2>

Une fois qu’un administrateur de l’organisation a configuré un émetteur JWT, les utilisateurs peuvent accéder aux projets W\&B à l’aide de JWT émis par ce fournisseur d’identité. Les JWT s’utilisent de la manière suivante :

1. Connectez-vous au fournisseur d’identité à l’aide de l’un des mécanismes disponibles dans votre organisation. Certains fournisseurs sont accessibles de manière automatisée via une API ou un SDK, tandis que d’autres ne sont accessibles que via l’interface utilisateur correspondante. Pour plus de détails, contactez l’administrateur de votre organisation W\&B ou le propriétaire de l’émetteur JWT.
2. Après avoir récupéré le JWT en vous connectant à votre fournisseur d’identité, stockez-le dans un fichier situé à un emplacement sécurisé. Indiquez le chemin absolu de ce fichier dans la variable d’environnement `WANDB_IDENTITY_TOKEN_FILE`.
3. Accédez à votre projet W\&B à l’aide du SDK ou de la CLI W\&B. Le SDK ou la CLI détecte automatiquement le JWT et, après l’avoir validé, l’échange contre un jeton d’accès W\&B. Ce jeton d’accès donne accès aux API nécessaires à vos flux de travail d’IA, comme la journalisation des runs, des métriques et des artifacts. Par défaut, le jeton d’accès est stocké dans `~/.config/wandb/credentials.json`. Vous pouvez modifier ce chemin à l’aide de la variable d’environnement `WANDB_CREDENTIALS_FILE`.

<Note>
  Les JWT sont des identifiants d’authentification de courte durée qui pallient les inconvénients des identifiants de longue durée, tels que les clés API et les mots de passe. La durée de validité du JWT dépend de la configuration de votre fournisseur d’identité. Actualisez le JWT avant son expiration et assurez-vous qu’il est bien stocké dans le fichier référencé par la variable d’environnement `WANDB_IDENTITY_TOKEN_FILE`.

  Le jeton d’accès W\&B a lui aussi une durée de validité par défaut, à l’issue de laquelle le SDK ou la CLI tente de l’actualiser à l’aide de votre JWT. Si, à ce moment-là, le JWT de l’utilisateur a également expiré sans avoir été actualisé, l’authentification échoue. Dans la mesure du possible, intégrez la récupération du JWT et son actualisation après expiration à la charge de travail d’IA qui utilise le SDK ou la CLI W\&B.
</Note>

<h3 id="jwt-validation">
  Validation du JWT
</h3>

Pour garantir que seuls des jetons valides donnent accès aux ressources, le JWT est soumis aux validations suivantes. Ces validations ont lieu lorsque le SDK ou la CLI échange le JWT contre un jeton d’accès W\&B, puis accède à un projet :

* W\&B vérifie la signature du JWT à l’aide du JWKS défini au niveau de l’organisation W\&B. Il s’agit de la première ligne de défense : si cette vérification échoue, le problème vient de votre JWKS ou de la manière dont votre JWT est signé.

* La revendication `iss` du JWT doit correspondre à l’URL de l’émetteur configurée au niveau de l’organisation.

* La revendication `sub` du JWT doit correspondre à l’adresse e-mail de l’utilisateur telle qu’elle est configurée dans l’organisation W\&B.

* La revendication `aud` du JWT doit correspondre au nom de l’organisation W\&B qui contient le projet auquel vous accédez dans le cadre de votre flux de travail d’IA.

  Sur les instances [Cloud dédié](/fr/products/wandb/platform/hosting/hosting-options/dedicated-cloud) ou [autogérées](/fr/products/wandb/platform/hosting/hosting-options/self-managed) :

  * Pour ignorer la validation de l’audience, vous pouvez définir la variable d’environnement `FEDERATED_AUTH_AUDIENCES` sur `wandb`.
  * Certaines organisations ont des exigences spécifiques concernant l’audience. Pour personnaliser la valeur `aud`, définissez la variable d’environnement `FEDERATED_AUTH_AUDIENCES` sur une chaîne contenant une liste de valeurs d’audience séparées par des virgules.

* W\&B vérifie la revendication `exp` du JWT afin de déterminer si le jeton est encore valide ou s’il a expiré et doit être actualisé.

<h2 id="external-service-accounts">
  Comptes de service externes
</h2>

W\&B prend en charge depuis longtemps des comptes de service intégrés dotés de clés API à longue durée de vie. Grâce à la fédération d’identités pour le SDK et la CLI, vous pouvez également utiliser des comptes de service externes qui s’authentifient à l’aide de JWT. Ces JWT doivent être émis par l’émetteur configuré pour l’organisation. Comme pour les comptes de service intégrés, un administrateur d’équipe peut configurer des comptes de service externes dans la portée d’une équipe.

Pour configurer un compte de service externe, un administrateur d’équipe doit :

1. Accéder à l’onglet **Service Accounts** de votre équipe.
2. Cliquer sur **New service account**.
3. Saisir un nom pour le compte de service.
4. Sélectionner **Federated Identity** comme **Authentication Method**, puis renseigner un **Subject**. Voir [Déterminer la valeur Subject pour votre fournisseur d’identité](#determine-the-subject-value-for-your-identity-provider).
5. Cliquer sur **Create**.

Le compte de service externe est alors enregistré auprès de l’équipe et peut accéder à W\&B à l’aide de JWT émis par le fournisseur d’identité configuré. La revendication `sub` du JWT du compte de service externe doit correspondre au sujet configuré par l’administrateur d’équipe dans l’onglet **Service Accounts** de l’équipe. W\&B vérifie cette revendication lors de la [validation du JWT](#jwt-validation). L’exigence relative à la revendication `aud` est semblable à celle qui s’applique aux JWT des utilisateurs humains.

Lorsque vous [utilisez le JWT d’un compte de service externe pour accéder à W\&B](#use-the-jwt-to-access-wb), il est souvent plus simple d’automatiser le flux de travail : l’automatisation génère le JWT initial, puis l’actualise au besoin. Pour attribuer à un utilisateur humain les runs journalisés à l’aide d’un compte de service externe, définissez la variable d’environnement `WANDB_USERNAME` ou `WANDB_USER_EMAIL` pour votre flux de travail d’IA, comme pour les comptes de service intégrés.

<Note>
  W\&B recommande de combiner comptes de service intégrés et externes pour vos charges de travail d’IA, selon leur niveau de sensibilité des données. Cette combinaison offre un bon équilibre entre flexibilité et simplicité.
</Note>

<h3 id="determine-the-subject-value-for-your-identity-provider">
  Déterminer la valeur Subject pour votre fournisseur d’identité
</h3>

La valeur que vous saisissez dans **Subject** doit correspondre exactement à la revendication `sub` (subject) des JWT émis par votre IdP pour le compte de service. W\&B applique la même comparaison quel que soit le fournisseur d’identité. La correspondance est exacte et sensible à la casse comme aux espaces : un simple espace final ou une différence de majuscules suffit à faire échouer l’authentification.

La W\&B App accepte toute valeur **Subject** non vide sans la valider, car cette valeur dépend entièrement de l’IdP. W\&B ne peut donc pas détecter une valeur incorrecte lors de la création du compte de service : l’authentification échoue plus tard, lorsque le compte de service présente son JWT.

Le moyen le plus fiable de déterminer la valeur correcte consiste à la lire dans un jeton réel. Obtenez un exemple de JWT émis pour le compte de service, décodez localement sa charge utile en base64url (le segment central, entre les deux points), puis copiez la valeur `sub` telle quelle dans le champ **Subject**. Ne collez jamais de JWT dans un décodeur en ligne tiers : un JWT est un identifiant d’authentification.

La valeur varie selon le fournisseur. Les valeurs suivantes sont courantes, mais vérifiez-les toujours à l’aide d’un jeton réel :

| Fournisseur d’identité | Où trouver la valeur `sub` |
| - | - |
| Microsoft Entra ID | L’**Object ID** du principal de service, disponible sous **Enterprise Applications** dans le [centre d’administration Microsoft Entra](https://entra.microsoft.com). Utilisez l’Object ID de l’**Enterprise Application** (principal de service), et non celui de l’**App registration**. Pour les jetons d’application uniquement (flux client credentials), c’est généralement la valeur qu’Entra ID place dans `sub`. |
| Google Cloud (GCP) | La valeur `sub` du jeton d’identité émis par Google pour le compte de service. |


## Related topics

- [Utiliser le Playground pour expérimenter avec des prompts](/fr/products/wandb/weave/guides/tools/playground.md)