Les API, interfaces de programmation d'applications, ont été créées dans le but d'exposer des données et des fonctions propriétaires à des tiers: l'énorme potentiel de l'outil va donc inévitablement de pair avec les risques découlant d'une exposition inconsciente des données.

La combinaison de l'authentification OAuth et des certificats SSL, en revanche, offre ce qu'il y a de plus avancé en termes de sécurité du système. Pour mieux comprendre de quoi il s'agit, commençons par l'un des éléments pivots de l'architecture pilotée par les API, celui qui permet de passer d'une forme d'authentification basique au standard OAuth, premier pas vers une architecture Zero Trust.

Voyons ce qu'est un token API et comment il fonctionne, et quelles sont les meilleures pratiques pour générer et gérer ses propres keys d'accès tout en limitant les risques associés à l'exposition des données via les API.

API et cybersécurité

Selon les analystes du secteur, l'utilisation inconsidérée des API pourrait rapidement devenir la porte d'entrée privilégiée des cyberattaques (Gartner, 2021). La diffusion rapide des API et des architectures pilotées par les API peut conduire les logiciels autant que les entreprises à s'exposer, via leurs applications web, à des failles de sécurité importantes, qui peuvent découvrir jusqu'à 40% de plus du "flanc" à protéger (Gartner, 2019).

Le problème ne vient pas d'un manque de sécurité des ressources: grâce aux communications chiffrées via des certificats SSL et à l'authentification OAuth via des en-têtes, les API offrent les plus hauts niveaux de protection disponibles dans l'informatique. Une étude réalisée en 2021 par Salt Security sur la sécurité des API souligne que plus de 25% des entreprises utilisant des API en production n'ont pas mis en place de stratégie de sécurité.

Si plus de 90 % des entreprises informatiques ont rencontré des problèmes de sécurité avec les API en 2020 (Gartner, 2021), c'est parce que s'il est vrai que le grand potentiel de l'intégration des API a été clair pour tout le monde dès le début, il est également vrai que l'on n'a pas accordé l'attention nécessaire à la question des risques liés à l'exposition des données à des tiers - ce qui est en fin de compte la tâche des interfaces de programmation d'applications, ou API.

API key et token API

L'architecture basée sur les API repose sur l'exposition de données et de fonctions à des tiers, il est donc crucial d'avoir une stratégie de défense consciente. Prenons l'exemple de l'exposition involontaire des API keys, l'une des failles les plus redoutées par les entreprises qui utilisent habituellement des API: il suffit qu'un seul développeur commette l'erreur de copier l'API key dans un forum ou un dépôt public, tel que GitHub ou Stack Overflow, pour exposer publiquement sa API key et permettre à n'importe quelle application de l'utiliser pour interroger des services web - évidemment au nom et pour le compte du détenteur de la key.

Les API keys sont des codes alphanumériques qui ne peuvent pas exploiter les mécanismes de contrôle typiques de l'authentification à deux facteurs, car elles consistent essentiellement en une chaîne de caractères opaque et cryptée sans signification évidente pour l'utilisateur. Ils peuvent toutefois être utilisés, dans la phase d'authentification de base, pour générer un token API, c'est-à-dire un titre d'accès sécurisé qui permet à l'utilisateur d'interagir - dans des limites fonctionnelles et temporelles bien définies - avec les services web requis.

Sur la place de marché OpenAPI, par exemple, la key API est générée au moment de l'inscription au service et peut être utilisée pour créer des token API via le service d'authentification OAuth, le protocole réseau standard le plus utilisé à ce jour pour garantir la sécurité des interactions via l'API.

Qu'est-ce qu'un token API?

Mais commençons par le commencement: un API token est une chaîne alphanumérique qui se trouve dans l'en-tête de chaque appel API et qui permet de tracer certaines informations sur l'utilisateur. Lorsque l'on parle d'appels entre API RESTful, notamment, l'en-tête (ou header) de chaque requête doit pouvoir indiquer

• le token d'autorisation, ou token API, au format Bearer
• la méthode HTTP, c'est-à-dire la spécification du type de requête (par exemple, supprimer)

Si la API key est l'identifiant de base qui permet d'accéder à toute place de marché API, le token API est le véritable "ticket d'entrée", celui qui permet de formuler un en-tête valide pour une demande API, c'est-à-dire de commencer à interagir avec des applications web tierces.

Le token API est une chaîne au format Bearer, c'est-à-dire littéralement "au porteur": cela signifie qu'il n'a pas de valeur nominale, mais qu'il appartient simplement à celui qui le possède. Il va sans dire que celui qui se retrouve en possession du token API d'un certain service web devient automatiquement capable d'effectuer des requêtes au nom et pour le compte de l'application en question.

C'est la raison principale pour laquelle le token API est souvent considéré comme une sorte de mot de passe, et la raison fondamentale pour laquelle il est recommandé d'en faire un usage conscient, comme c'est le cas pour les keys d'accès importantes.

De l'authentification de base à OAuth

Avec la génération d'un token API, nous passons de l'authentification de base à l'authentification OAuth, qui est parfaitement cohérente avec une architecture zéro confiance et suffisamment fiable pour permettre l'accès à des ressources de serveurs distants interrogés via l'API.

OAuth est une norme d'authentification qui permet de déléguer l'utilisation des identifiants d'accès aux ressources directement aux applications, sans impliquer l'utilisateur et ses identifiants personnels, tels qu'une key API, dans le processus.

C'est grâce à la norme OAuth que les tokens de porteur sont introduits à la place des identifiants nominaux, tels que les tokens API ou les tokens Web JSON (JWT), qui permettent aux applications web de se "présenter" directement au serveur et de lui indiquer qu'elles disposent de toutes les autorisations nécessaires pour poursuivre l'interaction.

Lorsque des données et des fonctions sont exposées via des API, il est également défini qui, comment, quand et avec quelles limitations peut y accéder. Pour envoyer une demande au serveur via l'API, il faut donc d'abord prouver que l'on dispose des autorisations nécessaires pour transmettre la demande. Le serveur peut vérifier tout cela à partir du token, sans avoir accès à des données sensibles telles que les informations d'identification de l'utilisateur final.

Fonctionnement des token API

Les token API, en tant que token "porteurs", ne nécessitent aucune spécification supplémentaire pour être utilisés. Une fois qu'un token API est généré, il est automatiquement inséré dans l'en-tête de tous les appels API effectués à l'aide de ces informations d'identification.

Chaque fois qu'un service web est interrogé, le serveur vérifie la validité de la demande précisément à partir de la validité du token API, qui représente à ce stade une sorte de "signature" apposée à chaque appel.

En plus de définir le point de départ de l'appel, le token API identifie les limites d'opération accordées à l'opérateur, qui peut, par exemple, avoir décidé en amont de n'utiliser que certaines méthodes HTTP ou de ne pouvoir interagir qu'avec certains endpoints, ou urls.

Outre une signature, le token API est également un ticket d'entrée très détaillé - compréhensible uniquement par le serveur et totalement illisible pour l'utilisateur - contenant toutes les options disponibles pour le demandeur.

Lorsqu'une application client souhaite accéder à des ressources protégées sur un certain serveur via l'API, elle signale par le biais du token qu'elle a reçu les autorisations nécessaires pour procéder. Mais elle doit également signaler tout ce qu'elle a l'intention de faire en utilisant ces informations d'identification, et pendant combien de temps.

Token API: Time To Leave et Scopes

En termes de sécurité, l'utilisation de tokens time-to-leave permet de limiter considérablement les risques de compromission d'un token : comme on peut facilement le deviner, un token est vulnérable tant qu'il fonctionne.

Les champs d'application, quant à eux, servent à définir les chemins que l'on peut emprunter et le type de demandes autorisées dans le cadre d'une interaction avec une application web. Il peut y avoir des tokens autorisés à utiliser toutes les fonctions (c'est-à-dire les méthodes HTTP) disponibles sur des points d'extrémité particuliers, mais il peut aussi y avoir des tokens dont l'utilisation est limitée à des méthodes précises (par exemple, uniquement GET et DELETE), mais qui peuvent être valides sur tous les points d'extrémité.

Pour générer un token API sur le Marketplace Openapi, par exemple, il suffit de saisir l'e-mail avec lequel on s'est abonné au service ainsi que la key API associée au compte, et d'indiquer précisément ces deux critères simples, sous la forme de

• la durée du token, c'est-à-dire l'indication du TTL (Time To Leave) associé au titre d'accès - ne dépassant pas 12 mois sur Openapi
• les champs d'application, c'est-à-dire les combinaisons de méthodes HTTP + Endpoint qui sont censées être utilisées lors de l'interrogation de l'API

Une fois que la date limite et les champs d'application du token API ont été définis, des limites claires sont établies qui définissent et limitent, en même temps, le champ d'application de la carte d'identité et la surface qu'elle expose à d'éventuels dangers.

 

Voulez-vous générer un token API ?
Connectez-vous à Openapi et commencez dès maintenant

GENERER TOKEN