Clés d'API ou OAuth pour les intégrations tierces

Ce que c'est

Une clé d'API est un secret statique délivré à une application et envoyé à chaque requête. L'antisèche OWASP REST Security (citée) présente les clés comme un contrôle contre le farming et les abus, et comme la base de plans d'utilisation ; elle note que les clés délivrées à des clients tiers sont relativement faciles à compromettre, et indique de ne pas s'appuyer exclusivement sur des clés d'API pour protéger des ressources sensibles, critiques ou de grande valeur. OAuth 2.0 (RFC 6749, citée) répond à un problème différent : permettre à une application tierce d'accéder aux ressources d'un utilisateur sans son mot de passe. La RFC énumère ce que le partage de mot de passe compromet, notamment le fait que les propriétaires de ressources ne peuvent pas révoquer l'accès d'un tiers en particulier sans tous les révoquer. Son octroi par code d'autorisation (authorization code grant) délivre des jetons d'accès à portée limitée ainsi que des jetons de rafraîchissement ; la RFC 6750 (citée) définit comment le jeton porteur (bearer) qui en résulte est présenté dans le champ d'en-tête de requête Authorization.

Pourquoi c'est important

Choisir des clés pour un cas d'usage délégué oblige les utilisateurs à remettre leurs identifiants, ou une clé toute-puissante, aux intégrateurs. Choisir OAuth pour un simple intégrateur serveur-à-serveur ajoute des redirections et une gestion de jetons dont personne n'a besoin.

Comment l'appliquer

• L'intégrateur agit pour son propre compte (ses propres données, sa facturation, ses quotas) : une clé d'API, ou l'octroi par identifiants client (client credentials) d'OAuth si un serveur d'autorisation est déjà exploité.
• L'intégrateur agit pour le compte des utilisateurs : OAuth par code d'autorisation avec des portées (scopes) ; les clients natifs et à page unique ajoutent PKCE.
• Dans les deux cas : envoyer les identifiants dans un en-tête, jamais dans l'URL, puisqu'OWASP note que les URL finissent dans les journaux ; n'afficher le secret qu'une seule fois à la création et ne stocker qu'un hachage ; laisser les propriétaires nommer, faire tourner (rotate) et révoquer chaque identifiant ; répondre 401 en cas d'identifiants absents ou invalides et 403 en cas de portée insuffisante.
• Donner aux clés un préfixe reconnaissable encodant le type et l'environnement, afin que des clés divulguées puissent être repérées par des scanners et révoquées.
• Limiter le débit et auditer par identifiant, non par compte, afin qu'une intégration compromise puisse être coupée seule.

Pièges

Des clés à longue durée de vie et sans portée intégrées dans du code de navigateur. Des serveurs de ressources OAuth qui valident le jeton mais omettent la vérification de portée. Traiter une clé comme l'authentification d'une personne, alors qu'elle identifie une application. Implémenter OAuth à partir de la seule RFC au lieu de déployer un serveur d'autorisation maintenu.