Choisissez le bon protocole de sécurité de l’API

Les protocoles d’authentification standard de l’industrie aident à réduire les efforts de sécurisation de votre API. Des protocoles de sécurité personnalisés peuvent être utilisés, mais seulement dans des circonstances très spécifiques. Voici un bref aperçu des avantages et des inconvénients des meilleurs protocoles.

Authentification API de base avec TLS

L’authentification API de base est la plus facile à implémenter, car la plupart du temps, elle peut être implémentée sans bibliothèques supplémentaires. Tout ce dont vous avez besoin pour implémenter l’authentification de base est généralement inclus dans votre infrastructure ou bibliothèque de langue standard. Le problème avec l’authentification de base est qu’elle est, bien « basique », et qu’elle offre les options de sécurité les plus basses des protocoles communs. Il n’y a pas d’options avancées pour utiliser ce protocole, donc vous envoyez juste un nom d’utilisateur et un mot de passe codé en Base64. L’authentification de base ne doit jamais être utilisée sans le chiffrement TLS (anciennement connu sous le nom de SSL) car la combinaison nom d’utilisateur / mot de passe peut être facilement décodée dans le cas contraire.

OAuth1

OAuth1  est le plus sécurisé des trois protocoles courants. OAuth1 est un protocole largement utilisé, testé, sécurisé et basé sur des signatures. Le protocole utilise une valeur de signature cryptographique (généralement HMAC-SHA1) qui combine le secret du jeton, le nonce et d’autres informations basées sur la requête. Le grand avantage de OAuth 1 est que vous ne passez jamais directement le secret de jeton à travers le fil, ce qui élimine complètement la possibilité pour quiconque de voir un mot de passe en transit. C’est le seul des trois protocoles qui peut être utilisé en toute sécurité sans SSL (bien que vous devriez toujours utiliser SSL si les données transférées sont sensibles). Cependant, ce niveau de sécurité a un prix: générer et valider des signatures peut être un processus complexe. Vous devez utiliser des algorithmes de hachage spécifiques avec un ensemble d’étapes strictes. Cependant, cette complexité n’est plus souvent un problème car chaque langage de programmation majeur dispose d’une bibliothèque pour gérer cela pour vous.

OAuth2

OAuth2 ressemble à une évolution de OAuth1, mais en réalité c’est une prise complètement différente sur l’authentification qui essaye de réduire la complexité. La spécification actuelle d’OAuth2 supprime les signatures, ainsi vous n’avez plus besoin d’utiliser d’algorithmes cryptographiques pour créer, générer et valider des signatures. Tout le chiffrement est maintenant géré par TLS, ce qui est maintenant requis. Il n’y a pas autant de bibliothèques OAuth2 que de bibliothèques OAuth1, donc tirer parti de ce protocole pour la sécurité de l’API REST peut être plus difficile.

L’année dernière, l’auteur principal et éditeur de la norme OAuth2 a démissionné, avec ce message informatif. En raison de cette instabilité dans le comité de spécifications et parce que les paramètres par défaut d’OAuth2 sont moins sûrs que OAuth1 (aucune signature numérique signifie que vous ne pouvez pas vérifier  si les informations ont été falsifiées avant ou après le transit), je recommanderais OAuth1 sur OAuth2 pour les applications de données sensibles. OAuth2 pourrait avoir un sens pour les environnements moins sensibles, comme certains réseaux sociaux.

Protocoles personnalisés

Les protocoles d’authentification API personnalisés doivent être évités à moins que vous ne sachiez réellement ce que vous faites et que vous compreniez parfaitement toutes les subtilités des signatures numériques cryptographiques. La plupart des organisations n’ont pas cette expertise, nous recommandons donc OAuth1.0a comme une alternative solide.

Même si vous êtes prêt à prendre cette route potentiellement périlleuse, il y a une autre raison de l’éviter: parce que c’est la coutume, personne d’autre que vous ne pourra l’utiliser facilement. Utilisez uniquement des protocoles d’authentification personnalisés si vous souhaitez prendre en charge les bibliothèques client que vous pouvez donner à vos appelants de l’API REST (Java, Ruby, PHP, Python, etc.) afin que vos utilisateurs puissent utiliser ces protocoles sans effort. Sinon, l’API sera ignorée.

Pourquoi utiliser les clés API par rapport à l’authentification par nom d’utilisateur / mot de passe

Une autre technique que nous utilisons est les clés API générées au lieu de l’authentification par nom d’utilisateur / mot de passe traditionnel. Cette décision est également très importante pour la sécurité de l’API. Voici donc les notes clés sur les API:

Entropie

Les clés / secrets d’API sont généralement une longue série de caractères aléatoires difficiles à deviner. Les noms d’utilisateur / mot de passe sont généralement beaucoup plus petits, utilisent des mots courants, ne sont généralement pas sécurisés et peuvent être soumis à des attaques par force brute ou par dictionnaire.

Problèmes liés à la réinitialisation des mots de passe

Les mots de passe sont souvent réinitialisés. Si vous utilisez le mot de passe dans le cadre de votre schéma d’authentification de l’API, l’accès à l’API échouera chaque fois que le mot de passe est modifié.

La vitesse

Les meilleures pratiques recommandent de crypter vos mots de passe dans la base de données pour limiter une éventuelle violation de données. Cela augmente les frais généraux pour chaque requête lors de l’authentification d’un utilisateur. L’authentification par clé API unique ignore l’étape de hachage et accélère donc vos appels.

Stockage de votre clé de sécurité API

J’encourage le stockage de la clé / du secret de l’API dans un fichier uniquement lisible par le propriétaire. Lorsque la paire clé / secret est téléchargée, elle est enregistrée dans le système de fichiers local. Les autorisations sont ensuite modifiées afin que seul l’utilisateur puisse lire le fichier. Cela limite l’exposition de la clé tout en gardant la clé disponible pour une utilisation avec nos SDK.

Utiliser des ID

Afin de réduire la sécurité de vos identifiants, vous devez les rendre opaques et uniques au monde. Au lieu d’utiliser « 1234 », utilisez « f6cd3459f9a39c9784b3e328f05be0f7 ». Ne pas utiliser de numéros séquentiels aide à empêcher les attaquants de « deviner » le numéro suivant (connu sous le nom d’attaque de fusion) et empêche la génération de UUID sur n’importe quel serveur au lieu d’attendre pour un seul serveur de base de données pour incrémenter automatiquement un ID.

Sessions et URL

Éviter les sessions pour notre API REST est une bonne pratique et contribue à améliorer les performances de notre serveur API. En plus d’éviter le surcoût d’un cluster de sessions (Base de données, Memcache, etc …), vous pouvez simplement ajouter des machines supplémentaires à votre cluster API afin de grandir avec votre base d’utilisateurs.

Lorsque vous implémentez un schéma d’autorisation (c’est-à-dire, des règles pour «qui peut voir quoi»), essayez de ne pas protéger les données ou les fonctionnalités en fonction d’une URL. Les URL peuvent changer avec le temps, utilisez plutôt la ressource elle-même ou son contenu comme ce que vous inspectez pour prendre vos décisions de contrôle d’accès.