Je suis tombé sur de nombreuses API qui donnent à l'utilisateur à la fois une API clé et une secrète. Mais ma question est: quelle est la différence entre les deux?
À mes yeux, une clé peut suffire. Disons que j'ai une clé et que moi et le serveur le savons. Je crée un hachage HMAC avec cette clé et fais un appel API. Sur le serveur, nous créons à nouveau le hachage HMAC et le comparons avec le hachage envoyé. Si c'est la même chose, l'appel est authentifié.
Alors pourquoi utiliser deux clés?
Edit: ou cette clé API est-elle utilisée pour rechercher le secret de l'API?
La cryptographie à clé secrète repose sur l'utilisation de la même clé pour coder puis décoder plus tard un message. Ainsi, seuls ceux qui connaissent le "secret" peuvent lire le message.
La sécurité RSA est basée sur 2 clés correspondantes. Il existe une clé publique pour chaque utilisateur, et tout le monde peut (devrait) la connaître. Il existe également une clé privée que seul l'utilisateur doit connaître. Un message chiffré par la clé publique ne peut être déchiffré que par la clé privée, et inversement.
Ainsi, si je veux vous envoyer un message que vous seul pouvez lire, j'obtiens (du réseau) votre clé publique, je crypte le message avec cette clé et vous êtes la seule personne qui peut le décrypter.
Ou, si je veux vous prouver que j'ai envoyé un message, je peux crypter le message avec ma clé privée, vous dire (en texte ouvert ou dans un autre message) comment il a été crypté. Ensuite, vous pouvez décrypter le message avec ma clé publique, et s'il devient lisible, vous savez qu'il vient de moi.
Cette forme de cryptage est assez gourmande en ordinateur, donc ce qui est parfois fait est de crypter une "clé secrète" unique avec la technologie RSA, puis de crypter le reste du message avec la clé secrète, puis de crypter ma signature de la deuxième façon. Vous inversez ensuite ce processus, donc si le message et la signature sont lisibles, vous seul pouvez le lire et vous êtes assuré que j'ai envoyé le message.
OR
vous pouvez visiter ce lien pour une explication plus détaillée.
Vous avez besoin de deux clés distinctes, l'une qui leur dit qui vous êtes, et l'autre qui prouve que vous êtes qui vous êtes.
La "clé" est votre ID utilisateur et le "secret" est votre mot de passe. Ils utilisent simplement les termes "clé" et "secret" parce que c'est ainsi qu'ils l'ont implémenté.
Réponse simple, si j'ai bien compris ...
Si vous utilisez votre clé API pour le chiffrement, comment le service saura-t-il qui les contacte? Comment décrypteront-ils ce message?
Vous utilisez la clé API pour indiquer qui vous êtes, c'est ce que vous envoyez en texte brut. La clé SECRET vous n'envoyez pas à personne. Vous l'utilisez simplement pour le cryptage. Ensuite, vous envoyez le message crypté. Vous n'envoyez pas la clé qui a été utilisée pour le chiffrement, cela irait à l'encontre du but.
Il y a des réponses expliquant ce qu'est la clé secrète et (publique). C'est une paire de clés publique-privée à laquelle ils donnent des noms confus. Mais personne ne dit pourquoi les API nécessitent les deux, et de nombreuses API ne vous donnent qu'un secret! Je n'ai également vu aucun document d'API expliquer pourquoi ils ont deux clés, donc le mieux que je puisse faire est de spéculer ...
Il est préférable de ne mettre que votre clé publique dans votre demande et de signer la demande localement avec votre clé privée; l'envoi de quelque chose de plus ne devrait pas être nécessaire. Mais certains s'en tirent avec juste le secret de la demande. Ok, toute bonne API utilisera une sécurité de transport comme TLS (généralement via HTTPS). Mais vous exposez toujours votre clé privée au serveur de cette façon, augmentant le risque qu'ils la gèrent d'une manière ou d'une autre (voir: le bug de journalisation des mots de passe de GitHub et Twitter a récemment été découvert). Et HTTPS est théoriquement tout aussi sécurisé, mais il existe toujours des failles d'implémentation.
Mais de nombreuses API, en fait la plupart, il vous semble que vous envoyez les deux clés dans les demandes, car c'est plus facile que de faire signer leurs propres signatures; ne peut pas avoir d'exemples cURL purs sinon! Dans ce cas, il est inutile de les séparer. Je suppose que les clés distinctes sont juste au cas où elles changeraient l'API plus tard pour en profiter. Ou certains ont une bibliothèque client qui pourrait le faire de manière plus sécurisée.