Quelle est la différence entre l'utilisation des clés API et des jetons API?
De toutes les recherches que j'ai faites, j'ai découvert que les clés API sont moins sécurisées que les jetons d'accès (sous l'utilisation de oAuth), et ne devraient être utilisées qu'à des fins de surveillance.
Mais d'après ce que j'ai compris, le serveur génère les deux. Donc, si je devais utiliser le même algorithme difficile pour créer mon jeton d'accès ou pour créer la clé API, cela ne les rendrait-il pas similaires? Des exemples aideraient la cause à mieux les comprendre car je n'en ai pas trouvé.
Quelques références: https://cloud.google.com/endpoints/docs/when-why-api-keyhttps://zapier.com/engineering/apikey-oauth -jwt /
Les clés d'API sont publiques, par intention. Ils sont un mécanisme d'autorisation, pas un mécanisme d'authentification (cela est mentionné dans vos liens). Peu importe comment ils sont générés mais il importe comment ils sont gérés. En d'autres termes: "toute personne disposant de cette clé peut entrer".
Ainsi, vous utilisez des clés API lorsque vous souhaitez autoriser et n'avez pas besoin de vous authentifier. Vous utilisez des jetons d'authentification, qui sont sécurisés dans la gestion, pour authentifier la connexion. En d'autres termes, "voici votre clé unique pour vous permettre d'entrer cette heure".
Une clé d'API typique pour une application REST est généralement beaucoup moins sécurisée que le contrôle d'accès fourni par un OAuth JWT (JSON Web Token) pour des raisons relatives à la messagerie de protocole de la couche application (commande) , syntaxe, protection des unités de données - ou absence de protection), par opposition à une protection résultant uniquement de l'utilisation d'un algorithme cryptographique, d'un mode et/ou d'une taille de clé particuliers. Cependant, je ne serais pas surpris si les générateurs de chaînes de clés API étaient plus prévisible que OAuth générateurs de chaînes de jetons d'accès. Les clés d'API sont souvent envoyées en HTTP [~ # ~] obtenez [~ # ~] paramètres de requête dans la première ligne d'une requête HTTP, comme illustré ici avec l'API JavaScript de Google Maps:
<script async defer src="https://maps.googleapis.com/maps/api/js key=YOUR_API_KEY&callback=initMap" type="text/javascript"></script>
En raison du fait que la chaîne de clé API est passée en tant que paramètre de requête HTTP [~ # ~] get [~ # ~] , c'est beaucoup plus facile pour les serveurs Web intermédiaires (y compris les proxys) et les navigateurs avec des langages de script côté client tels que JavaScript ou ActionScript pour obtenir un accès en lecture et/ou en écriture à la clé API. Comparez cela à d'autres types d'actions HTTP comme [~ # ~] mettez [~ # ~] ou [ ~ # ~] poste [~ # ~] où les paramètres de requête sont plus étroitement cachés des technologies susmentionnées. Presque tous les logiciels de serveur Web écriront la valeur d'attribut src dans le script tag ci-dessus pour access_log et/ou error_log fichiers y compris la clé API, comme les valeurs des variables de paramètre de requête font partie des variables d'environnement CGI (Common Gateway Interface): SCRIPT_PATH et QUERY_STRING . Reportez-vous à CWE-598 pour plus d'informations.
Les jetons d'accès OAuth, d'autre part, sont générés par session. L'attribution d'un jeton d'accès par un fournisseur d'authentification sécurisé ne se produira que lorsque le fournisseur aura reçu la preuve que l'utilisateur demandeur a droit aux privilèges demandés; une telle preuve peut être établie par la connaissance des informations d'identification (c'est-à-dire une paire de nom d'utilisateur et de mot de passe correspondante). D'autres fois, le contrôle d'accès peut être plus restrictif et les jetons d'accès ne sont fournis que pour un petit sous-ensemble de privilèges au sein d'une application/site/API particulier sous-composant, zone d'opération, sphère de contrôle, etc. Les autorisations finalement accordées à l'utilisateur final peuvent être aussi précises que l'administrateur système le souhaite. Notez que les jetons d'accès sont programmés pour expirer après un laps de temps défini et sont capables de fournir un contrôle d'accès discrétionnaire entre divers utilisateurs/groupes, privilèges/capacités, etc.
Les jetons d'accès sont souvent transférés en dehors de l'URL dans le champ d'autorisation de l'en-tête de requête HTTP, par exemple. Parfois, les implémentations du cadre d'authentification personnalisé provoquent la transmission du jeton dans un cookie qui a HttpOnly , Secure et Indicateurs SameSite activés - ou comme en-tête de requête HTTP personnalisé tel que X-Auth-Token tel que documenté publiquement pour le Cloud Storage SaaS d'Oracle: API du service de stockage Cloud d'Oracle :
Il est extrêmement rare que les en-têtes de requête HTTP et les valeurs des cookies soient enregistrés par un logiciel de navigateur/serveur Web; ils sont également plus difficiles d'accès par programme en raison de CORS (Cross Origin Resource Sharing.) En comparaison, les clés d'API passées en tant que paramètres HTTP GET peuvent être extraites avec du JavaScript côté client à partir du DOM (Document Object Model).
Pour ces raisons, la complexité requise pour obtenir des jetons d'accès à partir d'un cadre d'authentification tel que OAuth est beaucoup plus élevée que ce qui est nécessaire pour enregistrer l'utilisation d'une clé API. En outre, la robustesse de l'authentification et les cadres d'autorisation permettent au jeton d'accès d'être encapsulé dans le protocole HTTP d'une manière qu'il est assez difficile de visualiser ou de falsifier le jeton.