Authentification API en PowerShell : clés API, tokens Bearer et OAuth2

Sophie arrête le script de la leçon 9.1 : « Ton API météo est ouverte, très bien. Mais l’API de notre outil de ticketing, elle, va te demander de prouver qui tu es avant de te laisser créer le moindre ticket. » La quasi-totalité des API professionnelles exigent une authentification. Voici les trois mécanismes les plus courants que vous croiserez.

Clé API dans un en-tête personnalisé

Le mécanisme le plus simple : une clé secrète, fournie par le service, à transmettre dans un en-tête HTTP personnalisé (le nom exact de l’en-tête varie selon chaque API — X-API-Key est fréquent, mais pas universel) :

$headers = @{
    "X-API-Key" = "a1b2c3d4-nordika-secret"
}

Invoke-RestMethod -Uri "https://api.nordika-ticketing.local/tickets" -Headers $headers

On retrouve ici la syntaxe hashtable vue en 3.3 : $headers est simplement une hashtable, transmise telle quelle au paramètre -Headers.

Authentification Bearer : le standard le plus répandu

De très nombreuses API modernes (Microsoft Graph, vue en 8.2, en fait partie) utilisent un token Bearer, transmis dans l’en-tête Authorization :

$token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

$headers = @{
    "Authorization" = "Bearer $token"
}

Invoke-RestMethod -Uri "https://api.nordika-ticketing.local/tickets" -Headers $headers

Ce token n’est généralement pas fixe : il s’obtient via un premier appel d’authentification (souvent avec un identifiant client et un secret), et expire au bout d’un certain temps.

$identifiants = @{
    client_id     = "nordika-app"
    client_secret = "secret-a-ne-jamais-exposer"
    grant_type    = "client_credentials"
}

$reponseAuth = Invoke-RestMethod -Uri "https://api.nordika-ticketing.local/oauth/token" `
                                   -Method Post `
                                   -Body $identifiants

$token = $reponseAuth.access_token

Basic Authentication : identifiant et mot de passe encodés

Un mécanisme plus ancien, encore rencontré sur certaines API internes ou anciens systèmes :

$credential = Get-Credential

Invoke-RestMethod -Uri "https://api.nordika-legacy.local/data" -Credential $credential -Authentication Basic

Point de vigilance : Basic Authentication transmet l’identifiant et le mot de passe encodés en Base64 dans l’en-tête HTTP — pas chiffrés, simplement encodés. Cette méthode n’est acceptable que sur une connexion HTTPS (jamais en HTTP simple), sous peine d’exposer les identifiants en clair à quiconque intercepterait le trafic réseau.

Ne jamais coder un secret en dur dans un script

C’est le prolongement direct des principes de sécurité déjà vus en section 6 (comptes de service AD) et en section 8 (identifiants CI/CD) : une clé API ou un secret client codé en dur dans un script, surtout s’il est partagé via le module NordikaTools (section 6) ou versionné sur un dépôt Git (section 8), finit tôt ou tard par fuiter.

# À ne jamais faire dans un script destiné à être partagé ou versionné
$headers = @{ "X-API-Key" = "a1b2c3d4-nordika-secret" }

La bonne pratique, approfondie en détail dans la prochaine section dédiée à la sécurité, consiste à récupérer ce secret depuis un coffre-fort (SecretManagement) ou une variable d’environnement définie séparément du code :

$headers = @{ "X-API-Key" = $env:NORDIKA_TICKETING_API_KEY }

Retour d’expérience terrain : l’un des incidents de sécurité les plus fréquents et les plus évitables en entreprise reste la clé API ou le token oublié en clair dans un script poussé sur un dépôt Git, parfois même public par erreur. Des outils comme git-secrets ou le scan automatique de GitHub (GitHub Secret Scanning) détectent une partie de ces fuites, mais le vrai réflexe à adopter est de ne jamais écrire un secret en dur, même « juste pour tester » — un script de test a une fâcheuse tendance à finir en production tel quel.

Un exemple concret Nordika

# Récupération du secret depuis une variable d'environnement, jamais en dur
$clientSecret = $env:NORDIKA_TICKETING_SECRET

$reponseAuth = Invoke-RestMethod -Uri "https://api.nordika-ticketing.local/oauth/token" `
                                   -Method Post `
                                   -Body @{
                                       client_id     = "nordika-app"
                                       client_secret = $clientSecret
                                       grant_type    = "client_credentials"
                                   }

$headers = @{ "Authorization" = "Bearer $($reponseAuth.access_token)" }

$ticketsOuverts = Invoke-RestMethod -Uri "https://api.nordika-ticketing.local/tickets?statut=ouvert" -Headers $headers

Write-Output "$($ticketsOuverts.Count) ticket(s) ouvert(s) actuellement"

Source officielle : la documentation Microsoft Invoke-RestMethod détaille le paramètre -Authentication (valeurs Basic, Bearer, OAuth) disponible depuis PowerShell 6+, qui simplifie certains cas par rapport à la construction manuelle de l’en-tête Authorization.

Retenez le principe central de cette leçon, dans la droite ligne de tout ce qui a été dit sur la sécurité depuis la section 6 : le mécanisme d’authentification change d’une API à l’autre, mais la règle ne change jamais — un secret ne doit jamais apparaître en clair dans le code source d’un script.

Dans la prochaine leçon, on termine ce tour des API avec la gestion des erreurs propres au web, et la pagination des résultats.