Les clés d'API et OAuth répondent à des problèmes différents, et le choix entre les deux commence par une seule question : y a-t-il un tiers dans le schéma ?

Si votre serveur appelle l'API d'autrui en son propre nom, il vous faut une clé. Si l'application d'autrui appelle votre API au nom de votre utilisateur, il vous faut OAuth. Sans tiers dans l'histoire, OAuth ajoute du cérémonial sans ajouter de sécurité.

La suite : ce qui les distingue réellement, ce qui a changé dans OAuth ces dernières années, et une propriété des clés d'API dont presque personne ne parle, alors qu'elle détermine la façon dont vous vivrez avec elles en production.

La clé d'API : une chaîne qui dit « ce programme a le droit »

Une clé est une longue chaîne aléatoire que vous placez dans un en-tête de requête :

X-Api-Key: lix_live_9f2c...

Le serveur retrouve la clé, en déduit le compte auquel elle appartient et laisse passer la requête. Le mécanisme s'arrête là.

Les propriétés qui en découlent :

  • une clé n'expire pas d'elle-même. Elle vit jusqu'à ce que quelqu'un la révoque ;
  • une clé identifie un programme, pas une personne. Qui, dans l'équipe, a lancé l'appel reste généralement invisible ;
  • une clé donne accès à tout ce que le compte peut faire, sauf si vous en restreignez les droits séparément ;
  • la clé est l'unique secret. Si elle fuit, l'accès fuit : il n'y a pas d'étape intermédiaire.

OAuth : un protocole sur le consentement

OAuth 2.0 (RFC 6749) répond à une autre question. Il compte quatre participants : le propriétaire des données, l'application qui les veut, un serveur d'autorisation et le serveur qui détient les données.

Le déroulé est à peu près celui-ci. L'application envoie la personne sur la page du service lui-même. Celle-ci voit qui demande quoi, et accepte. L'application reçoit un code, l'échange contre un jeton d'accès et appelle l'API avec. Le jeton vit peu de temps — quelques minutes ou quelques heures ; à son expiration, l'application échange un jeton de rafraîchissement contre un nouveau.

Ce que cela apporte et qu'une clé ne peut pas apporter par construction :

  • le mot de passe de l'utilisateur n'arrive jamais à l'application. Tout le sens est là ;
  • les droits se découpent en portées. « Lire les liens » et « supprimer les liens » sont deux autorisations distinctes ;
  • le consentement est visible et révocable. L'utilisateur voit la liste des applications connectées et peut en déconnecter une sans toucher aux autres ;
  • les jetons expirent tout seuls. Un jeton d'accès volé ne vaut plus rien une heure après.

Le prix, c'est la complexité : un serveur d'autorisation, l'enregistrement des applications, un écran de consentement, le stockage et la rotation des jetons de rafraîchissement, et la gestion de l'expiration à chaque appel.

Comparaison selon les axes qui tranchent vraiment

Clé d'API OAuth 2.0
Qui est authentifié le programme l'utilisateur pour le compte duquel il agit
Durée de vie illimitée jeton d'accès : minutes à heures
Comment couper l'accès révoquer la clé révoquer le consentement ou le jeton
Étendue des droits en général tout le compte portées par action
Secret détenu par le tiers la clé elle-même des jetons seulement, jamais le mot de passe
Effort d'intégration un en-tête un serveur d'autorisation et le cycle complet
Où cela convient serveur à serveur, scripts, intégrations internes applications publiques, places de marché, « Se connecter avec… »

La règle de décision

La question n'est pas de savoir lequel est plus sûr dans l'absolu, mais qui délègue l'accès à qui.

Votre serveur → API d'autrui, compte le vôtre
    → clé d'API

Application tierce → votre API, compte de votre utilisateur
    → OAuth

Tâche planifiée, CI, intégration back-end
    → clé d'API

L'utilisateur doit voir et révoquer l'accès application par application
    → OAuth

La réception de postbacks est le cas d'école de la clé. Quand votre serveur signale au nôtre qu'une commande a été payée, aucun utilisateur ne participe à cet échange, personne n'est là pour consentir et aucun écran de consentement n'a sa place. Il en va de même pour les webhooks dans l'autre sens.

Ce qui a changé dans OAuth pendant que vous regardiez ailleurs

La moitié des articles sur le sujet décrivent OAuth tel qu'il était en 2015. Depuis, il s'est nettement resserré.

En janvier 2025, l'IETF a publié la RFC 9700, Best Current Practice for OAuth 2.0 Security. Le document rassemble des années d'expérience d'attaques réelles et déclare formellement obsolètes deux flux jusque-là jugés acceptables :

  • le flux implicite, celui qui renvoyait le jeton directement dans la barre d'adresse ;
  • resource owner password credentials, où l'application réclamait à l'utilisateur son identifiant et son mot de passe. Précisément ce qu'OAuth était censé supprimer.

Dans le même mouvement, PKCE est devenu obligatoire pour tous les types de clients, y compris côté serveur, et non plus seulement pour le mobile.

À savoir séparément : OAuth 2.1 est toujours à l'état de brouillon, et non une RFC publiée. Il regroupe les mêmes évolutions dans un seul document — PKCE obligatoire, comparaison exacte de l'URI de redirection, abandon des flux implicite et password, interdiction des jetons dans la chaîne de requête. Le citer comme norme en vigueur est prématuré.

Conséquence pratique : si un tutoriel OAuth propose le flux implicite, ce tutoriel a vieilli.

Le point faible des clés dont on parle rarement

Une clé n'expire pas. La révocation est donc votre seul levier. Et c'est là que ça se complique : la révocation n'est généralement pas immédiate.

Vérifier la clé à chaque requête revient à interroger la base de données. Sur une API au trafic réel, ce résultat est mis en cache. Chez nous, la correspondance entre clé et compte reste cinq minutes en cache. Entre le clic sur « révoquer » et l'arrêt effectif de l'accès, il s'écoule donc jusqu'à cinq minutes pendant lesquelles une clé compromise continue de fonctionner.

Ce n'est pas un oubli mais un échange : sans cache, chaque requête frappe la base. La plupart des API à clés passent un marché comparable, on le dit simplement rarement à voix haute. C'est important pour deux raisons. D'abord, lors d'une vraie fuite, révoquer la clé est le premier geste et non le dernier : il faut ensuite vérifier ce qui s'est passé pendant ces minutes. Ensuite, c'est exactement le problème que les jetons de courte durée d'OAuth attaquent par l'autre bout : ils expirent seuls, sans base de données.

Vivre avec des clés sans y laisser des plumes

Si les clés suffisent — et pour la plupart des intégrations elles suffisent —, le minimum ressemble à ceci :

  1. Ne conservez que l'empreinte. Le serveur compare l'empreinte de la clé présentée à celle qui est stockée ; la chaîne d'origine n'est montrée qu'une fois, à la création. Les nôtres sont vérifiées en SHA-256.
  2. Donnez un préfixe à la clé. Une chaîne de la forme lix_live_... est reconnue par les scanners de secrets dans les dépôts et les chaînes de journalisation.
  3. Une clé par intégration. Révoquer l'une n'emporte alors pas les autres, et le journal montre précisément ce qui a été compromis.
  4. Ne mettez jamais la clé dans la chaîne de requête. Les adresses finissent dans les journaux du serveur web, dans l'en-tête Referer et dans l'historique du navigateur. En-tête uniquement.
  5. Faites tourner selon un calendrier, pas après un incident. Une clé déjà renouvelée une fois se renouvelle vite. Une clé jamais renouvelée se révélera codée en dur à quatre endroits.
  6. Surveillez la date de dernière utilisation. Une clé inutilisée depuis six mois n'est pas une réserve, c'est une porte ouverte.

Ce que nous utilisons

L'API de Lix.li s'authentifie par clé : en-tête X-Api-Key, clés créées et révoquées depuis l'espace client, vérification par empreinte, limite de requêtes propre à chaque clé. Il n'y a pas d'OAuth, et c'est délibéré : les usages de l'API sont côté serveur — créer un lien, récupérer des statistiques, accepter une conversion — et aucun ne fait intervenir un tiers auquel l'utilisateur devrait donner son accord.

Si le besoin apparaissait de laisser des applications tierces entrer dans les comptes de nos clients, les clés ne suffiraient plus : l'utilisateur doit pouvoir voir à qui il a permis quoi et déconnecter une application sans casser les autres. C'est précisément là qu'OAuth cesse d'être un cérémonial pour devenir la seule option honnête.

Les appels eux-mêmes sont décrits dans la documentation de l'API, y compris les codes de réponse renvoyés pour une clé invalide et pour une clé révoquée. Sur un sujet voisin, l'explication de la raison pour laquelle une redirection 301 transforme un POST en GET mérite d'être lue par quiconque met en place la réception de postbacks : une requête authentifiée peut arriver avec une méthode différente de celle avec laquelle elle est partie.