Authentification Bearer Token

Sécuriser vos appels API

Chaque requête envoyée à l’API xAI doit être authentifiée. L’API utilise le schéma Bearer Token, un standard largement adopté dans les API REST. Cette leçon explique le fonctionnement de ce mécanisme et les bonnes pratiques pour protéger vos clés en production.

Le schéma Bearer Token

Le mot « Bearer » signifie « porteur » en anglais. Quiconque possède (porte) le token peut accéder à l’API. C’est pourquoi la protection de votre clé est fondamentale : il n’y a pas de vérification d’identité supplémentaire au-delà du token lui-même.

Format de l’en-tête

Chaque requête HTTP doit inclure l’en-tête Authorization avec le préfixe Bearer suivi de votre clé :

Authorization: Bearer xai-votre-cle-api

En cURL, cela donne :

curl https://api.x.ai/v1/responses \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "grok-4", "input": "Bonjour"}'

En Python, les SDKs gèrent cet en-tête automatiquement lorsque vous passez la clé au constructeur du client.

Erreurs d’authentification

HTTP 401 Unauthorized

Cette erreur indique que votre clé est absente, invalide ou révoquée. Vérifiez :

• Que la variable d’environnement XAI_API_KEY est bien définie
• Que la clé commence par xai-
• Que la clé n’a pas été révoquée dans la console

HTTP 403 Forbidden

Votre clé est valide mais n’a pas les permissions nécessaires pour l’action demandée. Cela peut arriver avec des restrictions d’équipe (team) sur certaines opérations.

Bonnes pratiques de sécurité

Ne jamais exposer une clé dans le code

Les clés ne doivent jamais apparaître en clair dans :

• Le code source versionné (Git)
• Les logs d’application
• Les URLs ou paramètres de requête
• Les messages d’erreur affichés aux utilisateurs
• Les issues et pull requests sur GitHub

Utiliser des coffres-forts de secrets

En production, stockez vos clés dans un système dédié :

• AWS Secrets Manager ou Parameter Store
• Google Secret Manager
• Azure Key Vault
• HashiCorp Vault
• Les secrets de votre plateforme CI/CD (GitHub Actions, GitLab CI)

Rotation des clés

Changez vos clés régulièrement et immédiatement en cas de suspicion de fuite :

1. Créez une nouvelle clé dans la console xAI
2. Mettez à jour la clé dans votre coffre-fort de secrets
3. Redéployez votre application
4. Vérifiez que tout fonctionne avec la nouvelle clé
5. Révoquez l’ancienne clé dans la console

Limiter les permissions

Si vous travaillez en équipe, créez des clés distinctes par service et par environnement. En cas de compromission, l’impact est limité à un seul contexte.

Détection de fuites

Le préfixe xai- des clés permet aux outils de détection (GitHub secret scanning, GitGuardian, TruffleHog) de les identifier automatiquement dans le code source. Activez ces outils dans vos dépôts pour être alerté immédiatement en cas d’exposition accidentelle.

Si une clé est détectée dans un commit public :

1. Révoquez-la immédiatement dans la console xAI
2. Vérifiez votre historique de consommation pour détecter un usage frauduleux
3. Créez une nouvelle clé
4. Nettoyez votre historique Git (ou mieux, considérez la clé comme compromise et passez à autre chose)

HTTPS obligatoire

L’API xAI n’accepte que les connexions HTTPS. Le protocole TLS chiffre vos requêtes en transit, y compris l’en-tête Authorization. N’essayez jamais de contourner cette protection : une requête en HTTP non chiffré exposerait votre clé sur le réseau.

Points clés à retenir

• L’API utilise le schéma Bearer Token via l’en-tête Authorization
• La clé est le seul facteur d’authentification : protégez-la comme un mot de passe
• Utilisez un coffre-fort de secrets en production, jamais de clé en dur
• Activez la détection de fuites dans vos dépôts Git
• Effectuez une rotation régulière et révoquez immédiatement toute clé compromise