Qu’est-ce que l’accès à une API ? Clés, OAuth et jetons

Qu’est-ce que l’accès à une API ?

L’accès à une API est le mécanisme qui décide qui peut l’appeler et ce que chaque appelant peut faire. Le client prouve son identité avec un identifiant tel qu’une clé d’API ou un jeton d’accès (authentification), et l’API vérifie les droits de cette identité pour l’action demandée (autorisation). Il permet aussi des limites de débit, une facturation et des journaux d’audit par consommateur.

Authentification et autorisation

• Authentification (AuthN) : qui appelle ? Une clé ou un jeton valide y répond.
• Autorisation (AuthZ) : a-t-il le droit de le faire ? Une clé valide peut quand même être refusée sur DELETE /orders/42 parce qu’elle n’a qu’un droit de lecture.

Il faut les deux. Beaucoup d’incidents réels ne viennent pas de mots de passe volés, mais de contrôles d’autorisation absents sur un endpoint qui faisait confiance à n’importe quel identifiant valide. Pour le volet sécurité, voir sécurité des API.

Les moyens courants de contrôler l’accès à une API

Clés d’API

Une longue chaîne aléatoire attribuée à chaque consommateur et envoyée dans un en-tête comme X-API-Key. Simple à mettre en place et adaptée aux appels de serveur à serveur, mais celui qui détient la clé a tout ce qu’elle autorise, et une clé divulguée fonctionne jusqu’à sa rotation. Détails dans qu’est-ce qu’une clé d’API.

Jetons d’accès OAuth 2.0

OAuth 2.0 (RFC 6749, en anglais) permet à un client d’obtenir un accès limité à une API. Le jeton d’accès est un identifiant pour des ressources protégées et porte une portée (scope) et une durée précises. Dans le flux Authorization Code, c’est un utilisateur qui accorde l’accès ; dans le flux Client Credentials, un client confidentiel comme un service backend obtient un jeton avec ses propres identifiants.

JWT

Un JSON Web Token est un format de jeton signé, souvent utilisé pour les jetons d’accès OAuth, qui contient des claims comme le sujet, les scopes et l’expiration. L’API peut vérifier la signature sans interroger de base de données. Revers de la médaille : un JWT reste valide jusqu’à son expiration, donc le révoquer plus tôt demande une infrastructure supplémentaire, et son contenu est lisible par quiconque le détient, il ne doit donc jamais contenir de secret. Vous pouvez inspecter l’en-tête et le contenu d’un jeton avec le décodeur JWT gratuit.

Bearer tokens

Ce n’est pas un mécanisme à part, mais la façon dont la plupart des jetons sont envoyés : Authorization: Bearer <token>. Celui qui porte le jeton obtient l’accès, il ne doit donc circuler qu’en HTTPS. Voir bearer token.

TLS mutuel (mTLS)

Le client et le serveur présentent chacun un certificat X.509 lors de la négociation TLS, et le certificat est l’identité. C’est solide entre services, mais coûteux à exploiter et peu pratique pour les navigateurs. La RFC 8705 (en anglais) décrit comment les clients OAuth l’utilisent et comment lier des jetons d’accès à un certificat client.

Un exemple de requête

GET /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK        (jeton valide, scope orders:read)
HTTP/1.1 401 Unauthorized  (jeton absent ou expiré)
HTTP/1.1 403 Forbidden     (jeton valide, scope manquant)

401 signifie que l’API ne sait pas qui vous êtes ; 403, qu’elle le sait et dit non. Les distinguer fait gagner beaucoup de temps de débogage.

Bonnes pratiques

• Moindre privilège. Délivrez des scopes étroits, pas des identifiants qui ouvrent tout.
• Jetons de courte durée. Des jetons d’accès brefs avec des refresh tokens révocables.
• Rotation et séparation. Faites tourner les clés selon un calendrier et utilisez des identifiants distincts par environnement.
• En-tête, pas URL. Les clés dans la query string finissent dans les journaux, l’historique du navigateur et les proxys.
• Limites de débit par consommateur. Le bug d’un client ne doit pas devenir la panne de tous.
• Journaliser l’identité. Sans cela, impossible de savoir à quoi une clé divulguée a accédé.
• Bien documenter l’authentification. Montrez des requêtes d’exemple complètes et le sens de chaque 401 et 403.

Erreurs fréquentes

• Authentifier sans autoriser chaque endpoint et chaque objet.
• Jetons de longue durée sans moyen de les révoquer.
• Une seule clé pour le développement et la production.
• Des secrets dans le code client, les dépôts ou les e-mails de support.
• Aucune gestion de l’expiration côté client, si bien qu’une expiration normale ressemble à une panne.

Tester et surveiller des API authentifiées

Une API qui fonctionne sans jeton ne prouve rien : les tests et contrôles doivent utiliser de vrais identifiants. Avec la surveillance d’API de LoadFocus, un contrôle peut envoyer des en-têtes et des bearer tokens OAuth et enchaîner des requêtes, par exemple se connecter, transmettre le jeton à l’appel suivant et vérifier chaque étape. Un test de charge qui saute l’authentification mesure un chemin que les vrais utilisateurs n’empruntent jamais, et l’émission des jetons devient souvent le goulot d’étranglement. Deux guides l’approfondissent : tests de performance d’API avec OAuth2 et tests de charge OAuth2 (tous deux en anglais). Voir aussi surveillance d’API.

Questions fréquentes : accès à une API

Quelle différence entre une clé d’API et un jeton d’accès OAuth ?

Une clé d’API est généralement un secret statique lié à un compte consommateur. Un jeton d’accès OAuth est émis par un serveur d’autorisation, a une courte durée de vie et porte des scopes. Utilisez des clés pour vos propres intégrations de serveur à serveur et OAuth quand des utilisateurs donnent à une application tierce l’accès à leurs données.

Les JWT sont-ils plus sûrs que les clés d’API ?

Ils ont des propriétés différentes, sans être meilleurs d’office. Un JWT porte une expiration et des scopes et se vérifie sans requête, mais il est difficile à révoquer avant son expiration. Une clé se révoque facilement, mais n’expire jamais d’elle-même. La sécurité dépend surtout de la façon dont vous stockez, limitez et renouvelez l’une comme l’autre.

Comment révoquer un JWT divulgué ?

Soit vous tenez côté serveur une liste de refus consultée à chaque requête, ce qui fait perdre l’avantage de l’absence d’état, soit vous gardez des jetons d’accès de courte durée pour qu’un jeton divulgué expire vite, et vous révoquez plutôt le refresh token.

Quelle différence entre 401 et 403 ?

401 Unauthorized signifie que la requête n’a pas d’authentification valide. 403 Forbidden signifie que l’appelant est authentifié mais n’a pas le droit d’effectuer l’action.

Quand utiliser le mTLS ?

Quand les deux côtés sont des services que vous maîtrisez et que vous voulez une identité fondée sur des certificats, ou quand une exigence de conformité le demande. Évitez-le pour les clients navigateur, où la gestion des certificats n’est pas praticable.

Comment tester en charge une API qui exige une authentification ?

Utilisez un compte de test ou un client OAuth dédié, obtenez le jeton dans le cadre du test et réutilisez-le sur plusieurs requêtes, et restez dans les limites de ce compte. N’utilisez jamais les identifiants d’utilisateurs réels de production.