Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi nous n'avons pas commencé par un SDK pour navigateur
Un SDK navigateur est facile à réclamer et c'est réellement une mauvaise idée pour une bonne partie de ce que fait vraiment une API de géocodage ou de recherche d'IP. Associer une adresse IP à un emplacement n'a de sens que parce que cela se fait sur le serveur, là où l'origine réelle de la requête est visible. Placez cette même recherche dans du JavaScript côté client exécuté dans le navigateur d'un visiteur et vous n'avez pas rendu l'intégration plus pratique. Vous avez déplacé une clé d'API authentifiée au seul endroit de tout le trajet de la requête où n'importe qui peut ouvrir les outils de développement et la lire.
C'est pourquoi nous n'avons pas fait passer un SDK navigateur avant la prise en charge HTTP simple et les hôtes de compatibilité. Une clé acceptée comme en-tête X-API-Key, jeton Bearer, authentification HTTP Basic ou paramètre de requête fonctionne de la même façon sur chaque hôte, appelée depuis l'endroit où votre code côté serveur se trouve déjà : un service backend, une fonction serverless, une tâche par lots, partout où la requête a déjà une raison de partir d'une infrastructure que vous contrôlez plutôt que d'un onglet de navigateur que vous ne contrôlez pas.
La géolocalisation d'IP, en particulier, n'a de sens que côté serveur. Toute la valeur de la recherche vient de la résolution de l'adresse IP qui envoie réellement la requête, ce qui, pour la plupart des cas d'usage significatifs (contrôles antifraude, localisation, statistiques que vous gérez vous-même au lieu de les vendre), doit se faire là où cette adresse IP fait autorité : votre serveur, qui reçoit directement la requête, et non un environnement de navigateur où l'« IP » que rapporterait un appel côté client est soit sans intérêt, soit très facile à usurper.
Le géocodage d'une adresse saisie est moins clairement réservé au serveur, et il existe un vrai argument pour vouloir une saisie semi-automatique d'adresses réactive directement dans un formulaire, dans le navigateur, sans aller-retour préalable par votre propre backend. Nous ne sommes pas opposés à ce que ce modèle existe un jour. Nous sommes opposés à ce qu'il soit construit comme premier et principal mode d'intégration, avant l'accès HTTP simple côté serveur dont la majorité des cas d'usage réels (parcours de paiement, calculateurs de frais de port, contrôles antifraude) ont réellement besoin et qui n'exige pas d'exposer un identifiant au public.
La tendance plus large que nous refusons consiste à traiter « propose un SDK navigateur » comme une case que chaque API est censée cocher, que l'accès côté client à ce type de données ait un sens ou non. Pour une recherche dont le contexte côté serveur est tout l'intérêt, un SDK navigateur répond surtout à une question marketing, « est-ce que cela a l'air moderne et pratique », au prix d'une vraie question de sécurité, « où cet identifiant va-t-il finir par se trouver ». Nous préférons répondre d'abord à la question de sécurité et laisser la commodité suivre, et non l'inverse.
Rien de tout cela n'exclut un outil plus léger, adapté au navigateur, à terme, limité précisément aux cas où l'usage côté client a réellement du sens, comme une saisie semi-automatique de formulaire qui n'a jamais besoin du véritable identifiant de votre compte pour fonctionner. Ce qu'il ne doit pas être, c'est la première chose à laquelle nous demandons à un client de faire confiance, avant le chemin HTTP simple qui couvre déjà en toute sécurité la majorité des intégrations réelles.