Comment implémenter un mécanisme de clé API
tout d'abord: je ne suis pas sûr du titre de la question, donc si vous avez une meilleure idée, n'hésitez pas à le dire (:
J'aimerais connaître des exemples de bonnes pratiques dans lesquels des services (comme Twitter ou co) qui proposent des API et souhaitent que vous, en tant que développeur, utilisiez une clé API empêchent des tiers d'obtenir cette clé.
Je vais expliquer mes salutations avec de mauvais exemples:
Pour autant que je sache, Twitter et FB vous obligent à utiliser des clés API pour les requêtes API. C'est bien pour les applications côté serveur, mais dès que vous soumettez votre clé à partir d'une application Web ou d'une application de bureau, la clé est visible pour les autres.
Parce que vous devez soumettre cette clé, il n'est pas très logique de la stocker en toute sécurité dans votre application. Pour la demande, elle doit être simple.
Une chose que vous pourriez faire est d'héberger votre propre service Web ou wrapper qui ajoute le côté serveur clé, puis achemine cette demande vers le serveur cible.
Mais cela n'est pas possible si Twitter/ou tout service que vous utilisez limite les demandes d'API par IP ou souhaite créer des statistiques basées sur IP.
Donc, pour résumer: si j'étais en mesure de créer une API pour d'autres et que je ne veux pas qu'ils utilisent SSL, quelles possibilités aurais-je pour m'assurer que leur clé est sûre et ne peut pas être facilement volée ?
La meilleure pratique est:
L'idée de base. Créez une clé API (une clé symétrique de 128 bits) pour chaque compte d'utilisateur distinct. Cette clé doit être stockée en toute sécurité sur le serveur, et également en toute sécurité sur le client de l'utilisateur.
Pour chaque demande faite par le client, ajoutez un paramètre de demande supplémentaire qui a une "signature" sur la demande entière. La "signature" doit être calculée comme S = MAC ( [~ # ~] k [~ # ~], [~ # ~] r [~ # ~]), où [~ # ~] k [~ # ~] est la clé API et [~ # ~] r [~ # ~] = est la demande entière, y compris tous les paramètres de demande. Ici, MAC doit être un algorithme de code d'authentification de message sécurisé, tel que AES-CMAC ou SHA1-HMAC.
Il appartient au client de calculer la signature et de la joindre à la demande; il est de la responsabilité du serveur de vérifier la signature et d'ignorer toute demande avec une signature invalide. Vous devrez peut-être également inclure un paramètre supplémentaire avec la demande qui identifie le compte d'utilisateur effectuant la demande.
Cela fournira l'authentification de la demande, mais pas la confidentialité ou la prévention de la relecture, et le client reçoit une réponse authentifiée du serveur.
Je suggère d'envoyer toutes les demandes via https (pas http). Cela fournira un niveau de sécurité supplémentaire contre un certain nombre de cas délicats. Les implications en termes de performances de cette opération sont moindres que vous ne le pensez - SSL a moins de frais généraux que la plupart des gens ne le pensent - donc ne jetez pas cette idée pour des raisons de performances vous avez en fait mesuré le surcoût de performance et trouvé cela inacceptable.
Autres éléments à surveiller. Vous souhaiterez peut-être utiliser un nonce à usage unique pour empêcher la relecture des demandes authentifiées. Je suggère d'utiliser une valeur aléatoire de force cryptographique (au moins 64 bits de long). Cela n'est pas nécessaire si vous utilisez https.
Assurez-vous que votre serveur est écrit pour se défendre contre attaques par pollution des paramètres de l'hôte (HPP) . Par exemple, il doit rejeter toute demande avec plusieurs paramètres de demande du même type (par exemple, http://example.com/foo.html?name=x&name=y). De plus, lors de l'écriture du code du serveur, soyez prudent lorsque vous créez de nouvelles demandes basées sur une demande que vous avez reçue. Par exemple, avant de traiter chaque demande, votre code serveur peut valider que la demande ne contient que la liste attendue des paramètres et rien de plus; ignorer les paramètres en double ou les paramètres inattendus avant de traiter la demande.
Attention à défauts de concaténation si vous décidez de protéger plusieurs valeurs avec le code d'authentification du message.