Workload Identity Federation :
sécuriser vos API Claude
Comment remplacer vos clés API statiques par des tokens courts qui expirent automatiquement. Disponible depuis le 17 juin 2026 sur la plateforme Claude.
Workload Identity Federation (WIF) permet à vos applications d’appeler l’API Claude sans stocker de clé API statique. Au lieu d’une clé sk-ant-… permanente, votre workload présente un token OIDC signé par votre fournisseur d’identité (AWS, GCP, GitHub Actions, Azure). Anthropic le valide et renvoie un token d’accès qui expire en quelques minutes.
Cette approche élimine le risque de fuite de clé API. Si un token est compromis, il expire automatiquement. Plus besoin de rotation manuelle ni de secrets dans vos pipelines CI/CD.
J’utilise l’API Claude quotidiennement depuis 2023 pour mes projets d’automatisation SEO et mes agents IA. Jusqu’à récemment, je stockais ma clé API dans des variables d’environnement, des fichiers .env, parfois même en dur dans des scripts de test. Chaque fois que je changeais de machine ou configurais un nouveau serveur, je devais transférer cette clé. Et chaque transfert représentait un risque de fuite.
Quand Anthropic a annoncé Workload Identity Federation le 17 juin 2026, j’ai immédiatement migré mes principaux workflows. Dans ce guide, je vous explique comment faire la même chose en moins de 15 minutes, que vous soyez sur AWS, GCP, Azure ou GitHub Actions.
Qu’est-ce que Workload Identity Federation exactement ?
Workload Identity Federation est un mécanisme d’authentification moderne qui permet à une application de prouver son identité sans utiliser de secret partagé. Au lieu de présenter une clé API (un secret que vous et Anthropic connaissez tous les deux), votre application présente un token signé par un tiers de confiance.
Ce tiers de confiance, c’est votre fournisseur d’identité : AWS IAM, Google Cloud, Microsoft Entra ID, GitHub Actions, Kubernetes, ou tout provider compatible OIDC (OpenID Connect). Vous configurez une relation de confiance entre Anthropic et votre provider. Ensuite, chaque fois que votre application a besoin d’appeler Claude, elle demande un token à son provider, le présente à Anthropic, et reçoit en échange un token d’accès Claude valide quelques minutes.
L’avantage fondamental : aucun secret permanent n’existe. Le token OIDC que votre application utilise est généré à la volée, signé cryptographiquement, et expire rapidement. Même si quelqu’un intercepte ce token, il sera inutilisable dans quelques minutes.
Pourquoi abandonner vos clés API statiques ?
Les clés API traditionnelles (sk-ant-…) posent plusieurs problèmes de sécurité que WIF résout élégamment. Commençons par le plus évident : le risque de fuite. Une clé API qui se retrouve dans un commit Git, un log de déploiement, ou un message Slack peut être exploitée immédiatement. Avec une clé statique, l’attaquant a accès à votre compte jusqu’à ce que vous révoquiez manuellement la clé.
Ensuite, il y a la gestion des rotations. Les bonnes pratiques de sécurité recommandent de faire tourner vos clés régulièrement. Mais en pratique, c’est pénible. Il faut mettre à jour tous les systèmes qui utilisent la clé, coordonner le changement, vérifier que rien ne casse. Beaucoup d’équipes repoussent cette tâche indéfiniment.
Avec WIF, ces deux problèmes disparaissent. Il n’y a plus de clé à faire fuiter puisqu’elle n’existe pas. Et la rotation est automatique : chaque token a une durée de vie de quelques minutes. Votre infrastructure de sécurité passe de réactive (détecter et révoquer les fuites) à proactive (aucune fuite possible par design).
Comment fonctionne WIF techniquement ?
Le flux WIF repose sur trois composants que vous configurez dans la console Claude. Premièrement, l’issuer (émetteur) : c’est l’URL de votre fournisseur d’identité. Par exemple, https://token.actions.githubusercontent.com pour GitHub Actions. Anthropic utilisera cette URL pour récupérer les clés publiques qui vérifient les signatures des tokens.
Deuxièmement, le service account (compte de service) : c’est l’identité sous laquelle vos workloads agiront dans l’organisation Anthropic. Vous lui attribuez des rôles (lecture, écriture, admin) et des quotas. Chaque équipe ou projet peut avoir son propre service account avec des permissions différentes.
Troisièmement, la federation rule (règle de fédération) : elle définit quels tokens OIDC peuvent s’authentifier comme ce service account. Par exemple, vous pouvez dire seuls les tokens GitHub Actions provenant du repo monorg/monrepo sur la branche main peuvent utiliser ce service account. C’est un filtrage très fin.
Le flux d’authentification en 4 étapes
Voici ce qui se passe à chaque appel API avec WIF. Étape 1 : votre application demande un token OIDC à son provider local. Sur GitHub Actions, c’est automatique via les permissions du workflow. Sur AWS, c’est via le metadata service EC2 ou ECS. Étape 2 : votre application envoie ce token OIDC à Anthropic.
Étape 3 : Anthropic vérifie la signature du token (via les clés publiques de l’issuer), vérifie que les claims du token matchent votre federation rule, puis génère un token d’accès Claude. Étape 4 : votre application utilise ce token Claude pour appeler l’API comme d’habitude. Le SDK Python ou TypeScript gère automatiquement le refresh avant expiration.
Les 6 avantages concrets de WIF pour vos projets Claude
WIF n’est pas qu’une amélioration théorique de la sécurité. Voici les bénéfices pratiques que j’ai constatés après migration de mes workflows.
- Zéro secret à gérer : plus de fichier .env avec des clés sensibles, plus de secrets dans les gestionnaires de mots de passe, plus de variables CI à synchroniser entre environnements.
- Audit trail complet : chaque service account a son propre historique d’appels. Vous savez exactement quel workflow a consommé quels tokens, quand, et combien.
- Permissions granulaires : un service account pour la prod avec tous les droits, un autre pour les tests avec des quotas limités. Isolation parfaite entre environnements.
- Révocation instantanée : si un workflow est compromis, vous supprimez la federation rule. Effet immédiat, sans impacter les autres systèmes.
- Conformité simplifiée : pour les audits SOC2, ISO 27001 ou RGPD, démontrer qu’aucun secret permanent n’existe est un argument massue.
- Onboarding équipe accéléré : un nouveau développeur n’a pas besoin de recevoir de clé API. Il configure son environnement, et WIF fait le reste.
Quels fournisseurs d’identité sont supportés ?
WIF fonctionne avec tout provider compatible OIDC. Voici les trois catégories principales que vous rencontrerez en entreprise.
Cloud providers majeurs
AWS IAM (via OIDC tokens), Google Cloud (Service Account tokens), Microsoft Entra ID (ex-Azure AD). Configuration native dans chaque console cloud.
CI/CD et orchestration
GitHub Actions (OIDC natif depuis 2021), GitLab CI, CircleCI, Jenkins avec plugins OIDC. Parfait pour les pipelines de déploiement automatisés.
Kubernetes et conteneurs
SPIFFE/SPIRE, Kubernetes ServiceAccount tokens. Idéal pour les architectures microservices où chaque pod a sa propre identité.
Clé API statique vs WIF : le comparatif complet
Voici un tableau récapitulatif pour visualiser les différences entre l’ancienne méthode (clé API) et WIF.
Configurer WIF avec GitHub Actions : tuto pas à pas
GitHub Actions est probablement le cas d’usage le plus courant pour WIF. Voici comment configurer l’authentification en 10 minutes. Première étape : dans la console Claude, allez dans Settings puis Workload identity et cliquez Connect workload. Sélectionnez GitHub Actions.
L’assistant vous demande trois informations : le nom de l’issuer (GitHub), l’URL de l’issuer (https://token.actions.githubusercontent.com), et les claims à matcher. Pour les claims, vous pouvez filtrer par organisation, repository, branche, ou même par environment GitHub.
Le code Python côté application
Côté Python, le SDK Anthropic gère automatiquement l’échange de tokens. Vous n’avez plus besoin de passer api_key au constructeur.
Configurer WIF avec AWS et Google Cloud
Pour AWS, le principe est similaire mais vous utilisez les tokens OIDC générés par AWS STS (Security Token Service). Vos applications EC2, ECS, Lambda ou EKS peuvent toutes obtenir un token OIDC via le metadata service ou les credentials providers natifs.
Dans la console Claude, créez un issuer avec l’URL de votre provider AWS (format sts.amazonaws.com ou via un OIDC provider custom dans IAM). Configurez ensuite une federation rule qui matche le ARN du rôle IAM de vos workloads.
Google Cloud : Cloud Run, Cloud Functions, GKE
Pour Google Cloud, vos workloads obtiennent un token d’identité via le metadata server (http://metadata.google.internal). Ce token est signé par Google et contient l’identité du service account GCP de votre application.
Dans la console Claude, l’issuer est https://accounts.google.com. La federation rule filtre sur les claims du token, notamment l’email du service account GCP (format mon-sa@mon-projet.iam.gserviceaccount.com). Seuls les workloads tournant sous ce service account pourront s’authentifier.
Les bonnes pratiques pour une migration réussie vers WIF
Avant de migrer tous vos workloads en production vers WIF, voici quelques recommandations issues de mon expérience terrain. Premièrement, commencez par un environnement de test. Créez un service account dédié avec des quotas limités, configurez WIF sur un workflow non critique, et validez que tout fonctionne.
Deuxièmement, gardez une clé API de secours (désactivée) pendant la transition. Si WIF pose un problème en production, vous pouvez réactiver temporairement la clé le temps de débugger. Une fois confiant, supprimez cette clé de secours.
Troisièmement, documentez vos federation rules. Chaque règle devrait avoir un nom descriptif et une description expliquant quel système l’utilise. Dans 6 mois, quand quelqu’un devra modifier la config, cette documentation sera précieuse.
Quatrièmement, surveillez les métriques. La console Claude affiche les authentifications WIF par service account. Vérifiez régulièrement qu’il n’y a pas de pics anormaux ou de tentatives échouées qui pourraient indiquer une mauvaise configuration.
Le flux WIF : votre workload obtient un token OIDC, l’échange contre un token Claude, puis appelle l’API.
Aller plus loin avec l’API Claude
WIF n’est qu’une brique de l’écosystème Claude pour les développeurs. Une fois l’authentification sécurisée, vous pouvez explorer les fonctionnalités avancées : streaming de réponses, function calling, vision, et bien sûr Claude Code pour le développement assisté par IA.
Si vous voulez maîtriser tous ces aspects, j’ai construit une guide Claude IA complet qui couvre les cas d’usage avancés, de l’API aux agents autonomes. C’est le complément idéal pour passer de la théorie à la pratique.
Questions fréquentes sur Workload Identity Federation Claude
Qu’est-ce que Workload Identity Federation pour Claude ?
Workload Identity Federation (WIF) est un mécanisme d’authentification qui permet à vos applications d’accéder à l’API Claude sans utiliser de clé API statique. Au lieu de stocker un secret permanent, votre application présente un token OIDC signé par votre fournisseur d’identité (AWS, GCP, GitHub Actions, Azure).
Anthropic vérifie ce token et renvoie un token d’accès Claude qui expire en quelques minutes. Cette approche élimine le risque de fuite de clés API et simplifie la gestion des accès. Vous n’avez plus de secret à faire tourner manuellement, et chaque workload peut avoir sa propre identité avec des permissions granulaires.
Quels fournisseurs d’identité sont compatibles avec WIF Claude ?
WIF Claude fonctionne avec tout fournisseur compatible OIDC (OpenID Connect). Les providers officiellement documentés incluent AWS IAM, Google Cloud (Cloud Run, Cloud Functions, GKE), Microsoft Entra ID (ex-Azure AD), GitHub Actions, GitLab CI, et Kubernetes via SPIFFE/SPIRE.
Vous pouvez également utiliser d’autres providers OIDC comme Okta, Auth0, ou Keycloak si votre entreprise a déjà une infrastructure d’identité. L’essentiel est que le provider expose un endpoint JWKS (JSON Web Key Set) pour que Anthropic puisse vérifier les signatures des tokens.
WIF est-il gratuit ou y a-t-il un coût supplémentaire ?
Workload Identity Federation est inclus sans frais supplémentaires dans tous les plans Claude, y compris les plans Team et Enterprise. Vous ne payez que pour les tokens API consommés, comme avec une clé API classique. Il n’y a pas de surcoût pour l’authentification WIF.
Cependant, certaines fonctionnalités avancées comme la gestion fine des service accounts et les audit logs détaillés peuvent être réservées aux plans Enterprise. Vérifiez les spécifications de votre plan dans la console Claude pour connaître les limites exactes.
Puis-je utiliser WIF et une clé API en même temps ?
Oui, vous pouvez utiliser les deux méthodes en parallèle pendant une période de transition. Anthropic n’impose pas de choix exclusif. Vous pouvez avoir certains workloads authentifiés via WIF et d’autres via clé API statique, le temps de migrer progressivement.
Cependant, pour bénéficier pleinement des avantages de sécurité de WIF, je recommande de migrer tous vos workloads et de supprimer ensuite les clés API inutilisées. Garder une clé API active réduit les bénéfices de WIF puisqu’elle reste un vecteur de fuite potentiel.
Comment configurer WIF avec GitHub Actions ?
Pour configurer WIF avec GitHub Actions, commencez par créer un issuer dans la console Claude avec l’URL https://token.actions.githubusercontent.com. Ensuite, créez un service account et une federation rule qui filtre sur les claims GitHub (organisation, repository, branche).
Côté workflow GitHub, ajoutez la permission id-token: write pour autoriser l’obtention du token OIDC. Passez les variables ANTHROPIC_FEDERATION_RULE_ID, ANTHROPIC_ORGANIZATION_ID et ANTHROPIC_SERVICE_ACCOUNT_ID à votre application. Le SDK Anthropic Python ou TypeScript gère automatiquement l’échange de tokens.
Quelle est la durée de validité d’un token WIF Claude ?
Les tokens d’accès Claude obtenus via WIF ont une durée de validité courte, généralement de quelques minutes (la durée exacte peut varier). Cette courte durée est intentionnelle : c’est ce qui garantit la sécurité du système. Un token compromis devient rapidement inutilisable.
Le SDK Anthropic gère automatiquement le renouvellement des tokens avant expiration. Votre code applicatif n’a pas besoin de se soucier de la durée de vie des tokens. Le SDK détecte l’approche de l’expiration et effectue un nouvel échange OIDC en arrière-plan.
WIF fonctionne-t-il avec Claude Code ?
Oui, Workload Identity Federation est compatible avec Claude Code, l’outil de développement assisté par IA d’Anthropic. Vous pouvez configurer Claude Code pour utiliser WIF au lieu d’une clé API, ce qui est particulièrement utile dans les environnements CI/CD.
Pour les sessions interactives Claude Code sur votre machine locale, vous pouvez utiliser la commande claude auth login qui utilise un flux OAuth distinct. WIF est surtout pertinent pour les usages automatisés (pipelines, serveurs, conteneurs) où il n’y a pas d’utilisateur humain pour s’authentifier.
Que se passe-t-il si ma federation rule est mal configurée ?
Si votre federation rule est mal configurée, l’échange de tokens échouera et vous obtiendrez une erreur d’authentification. L’erreur indiquera généralement que les claims du token OIDC ne matchent pas les conditions de la rule. Par exemple, si vous filtrez sur la branche main mais exécutez depuis develop.
Pour débugger, vérifiez d’abord que les claims de votre token OIDC correspondent exactement à votre rule. Vous pouvez décoder le token (c’est un JWT) pour voir son contenu. Ensuite, vérifiez l’URL de l’issuer, l’ID du service account, et les permissions du workflow qui demande le token.
Comment auditer les accès WIF à mon compte Claude ?
La console Claude affiche les authentifications et appels API par service account. Vous pouvez voir quels service accounts ont été utilisés, quand, combien de tokens ont été consommés, et depuis quels issuers. Cette granularité d’audit est bien supérieure aux clés API classiques.
Pour un audit approfondi, exportez les logs via l’API d’administration Claude (disponible sur les plans Enterprise). Vous pouvez intégrer ces logs à votre SIEM (Splunk, Datadog, etc.) pour corréler les accès Claude avec vos autres événements de sécurité.
Puis-je révoquer un accès WIF instantanément ?
Oui, vous pouvez révoquer un accès WIF instantanément en supprimant la federation rule correspondante dans la console Claude. Dès la suppression, les tokens OIDC provenant de ce workload ne pourront plus être échangés contre des tokens Claude. L’effet est immédiat.
Notez que les tokens Claude déjà émis restent valides jusqu’à leur expiration naturelle (quelques minutes). Pour une révocation totale et immédiate, vous pouvez également désactiver le service account associé, ce qui invalide tous les tokens en cours. Cette double action garantit une coupure complète.
