L'API Claude prend en charge deux méthodes d'authentification des requêtes :
| Méthode | Identifiant | Idéal pour |
|---|---|---|
| Clé API | Secret statique sk-ant-api... dans l'en-tête x-api-key | Développement local, prototypage, scripts et serveurs mono-locataires où vous contrôlez le stockage des secrets |
| Workload Identity Federation | Jeton bearer de courte durée échangé à partir du jeton d'identité de votre fournisseur d'identité | Charges de travail en production sur des plateformes cloud (AWS, Google Cloud, Azure), pipelines CI/CD et Kubernetes, où vous souhaitez éliminer les secrets statiques |
Les deux méthodes accordent le même accès aux points de terminaison de l'API Claude. Choisissez les clés API pour démarrer rapidement, et passez à la Workload Identity Federation lorsque votre charge de travail dispose déjà d'une identité émise par la plateforme que vous pouvez fédérer.
Les clés API sont des secrets statiques que vous générez dans la Claude Console et que vous transmettez à chaque requête.
x-api-key sur les requêtes HTTP directes, ou définissez la variable d'environnement ANTHROPIC_API_KEY et les SDK clients la récupèrent automatiquement.POST /v1/messages
x-api-key: YOUR_API_KEY
anthropic-version: 2023-06-01
content-type: application/jsonStockez les clés API dans un gestionnaire de secrets, effectuez une rotation périodique et révoquez toute clé dont vous soupçonnez la fuite. Vous pouvez également définir une expiration lors de la création d'une clé pour limiter la durée pendant laquelle un identifiant divulgué reste utilisable.
client = Anthropic(api_key="my-anthropic-api-key")
# ou, avec ANTHROPIC_API_KEY définie dans l'environnement :
client = Anthropic()Lorsque vous créez une clé API depuis la page API keys dans la Claude Console, vous choisissez une expiration : une valeur prédéfinie (3 heures, 1 jour, 7 jours ou 30 jours), une durée personnalisée, ou Never pour les clés que vous stockez dans un gestionnaire de secrets et dont vous gérez vous-même la rotation. Si votre organisation dispose d'une politique d'expiration maximale, la Console limite les valeurs prédéfinies et les durées personnalisées au maximum défini par la politique, et Never n'est pas disponible. Les clés existantes conservent leur comportement actuel ; l'expiration est définie au moment de la création et ne peut pas être modifiée par la suite. Le même choix d'expiration s'applique lorsque vous créez une clé Admin API dans la Claude Console.
Anthropic envoie un e-mail au créateur de la clé à l'approche de l'expiration : 7 jours avant l'expiration pour les clés créées avec une durée de vie d'au moins 14 jours, et 1 jour avant pour les clés avec une durée de vie d'au moins 7 jours. Les clés avec des durées de vie plus courtes expirent sans e-mail d'avertissement.
Après l'expiration d'une clé, les requêtes effectuées avec celle-ci renvoient une erreur 401 authentication_error. Créez une nouvelle clé pour rétablir l'accès ; les clés expirées ne peuvent pas être réactivées.
Le tableau des clés API de la Console affiche l'expiration de chaque clé, et l'Admin API indique l'horodatage expires_at de chaque clé sur les points de terminaison List API Keys et Retrieve API Key, afin que vous puissiez auditer et effectuer la rotation des clés avant leur expiration. Le champ est null pour les clés sans expiration.
L'expiration limite la durée de vie d'un identifiant divulgué, mais elle ne remplace pas une bonne hygiène des secrets. Indépendamment de l'expiration, stockez les clés dans un gestionnaire de secrets et révoquez toute clé dont vous soupçonnez la fuite.
La « Workload Identity Federation » (fédération d'identité de charge de travail), ou WIF, permet à une charge de travail de s'authentifier avec un jeton d'identité de courte durée émis par un « identity provider » (fournisseur d'identité), ou IdP, auquel vous faites déjà confiance, tel qu'AWS IAM, Google Cloud, ou tout émetteur OIDC conforme aux normes (comme GitHub Actions, les comptes de service Kubernetes, SPIFFE, Microsoft Entra ID ou Okta). La charge de travail échange son JWT émis par l'IdP via POST /v1/oauth/token contre un jeton d'accès à l'API Claude de courte durée, et le SDK actualise automatiquement ce jeton avant son expiration. Il n'y a aucune chaîne sk-ant-api... à créer, distribuer ou faire tourner.
La fédération élimine les clés API Claude de longue durée de votre environnement, ce qui réduit le rayon d'impact d'un identifiant divulgué et vous permet de gérer l'accès avec les mêmes contrôles IdP que vous utilisez déjà pour les ressources cloud. Elle ne garantit pas, à elle seule, une sécurité de bout en bout : la chaîne de confiance n'est aussi solide que la configuration de votre fournisseur d'identité, et un secret de longue durée situé un cran en amont (par exemple, un identifiant cloud statique capable de créer des jetons IdP) peut toujours la compromettre. Associez la fédération aux contrôles de votre fournisseur, tels que les listes d'autorisation d'adresses IP, la MFA et la journalisation d'audit.
Pour configurer la fédération, vous créez trois ressources dans la Claude Console (un compte de service, un émetteur de fédération et une règle de fédération), puis vous pointez votre SDK vers la règle. Consultez Workload Identity Federation pour le guide de configuration complet.
Configurez les émetteurs, les règles et les comptes de service, puis échangez les jetons
Guides étape par étape pour AWS, Google Cloud, Azure, GitHub Actions, Kubernetes, SPIFFE et Okta
Variables d'environnement, règles de validation, configuration de profil et référence des erreurs
Python, TypeScript, C#, Go, Java, PHP, Ruby et la CLI
Was this page helpful?