Le nouveau trio AAA : API, authentification et disponibilité

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Vous l’aurez peut-être compris : oui, je fais partie de ces gens qui jouent à Pokémon Go. Ou plutôt, comme c’est souvent le cas ces derniers temps, qui ne jouent pas à Pokémon Go. Et c’est embêtant, car cela signifie aussi que notre benjamin ne peut pas jouer : il se trouve que nous utilisons tous les deux des comptes du Club des Dresseurs Pokémon (PTC), et non des comptes Google, et que nous n’arrivons pas à nous connecter.

C’est important, car si nous sommes tous les deux frustrés de ne pas pouvoir nous « authentifier » et nous connecter pour jouer, mon mari, lui, a choisi d’utiliser son compte Google et, eh bien, il ne rencontre pas les mêmes problèmes.

Ce qui m’a amenée à me pencher sur certaines problématiques techniques qui devraient véritablement interpeller toutes les entreprises, quelle que soit l’application qu’elles lancent. Ces problématiques s’articulent autour du nouveau triptyque AAA : API, authentification et disponibilité.

Fait intéressant, cette quête a commencé lorsque je lisais un article de Forbes sur le suivi des Pokémon dans Pokémon Go. Oui, Forbes. Le phénomène est à ce point important. Quoi qu’il en soit, cela m’a conduit à lire un autre article, puis encore un autre, dont l’un avançait que si le suivi ne fonctionnait pas (du moins au début), c’était à cause d’une mise à jour du jeu dans laquelle une clé API avait été omise par inadvertance des appels de suivi envoyés aux serveurs de Niantic.

Que ce soit le cas ou non, une telle bévue suffirait effectivement à rendre les API inopérantes. Mais une question me revenait sans cesse : si je ne pouvais pas me connecter à mon compte PTC pour jouer, pourquoi pouvais-je passer à mon compte Google et me connecter les doigts dans le nez ?

Le lien entre l’API et l’authentification

Eh bien, cela m’a poussé à fouiller sur github et à éplucher les API de Pokémon Go (je préfère Java, mais il y a aussi Python, alors faites-vous plaisir), et c’est là que j’ai enfin eu le déclic. En effet, presque tous les appels d’API de ces dépôts gèrent la même exception : LoginFailedException.

Autrement dit, même un simple appel visant à trouver des Pokémon à proximité peut entraîner une LoginFailedException.

Ce qui n’est vraiment pas si surprenant. En effet, les applications web monolithiques suivent souvent les utilisateurs authentifiés au moyen de sessions, ce qui implique généralement un cookie contenant un identifiant de session ou un autre jeton que l’application vérifie avant toute autre opération (il s’agit d’une architecture avec état pour ceux qui suivent). Les API ne sont pas très différentes : chaque appel d’API doit permettre de vérifier que l’application à l’origine de l’appel (l’utilisateur) est bien autorisée à l’effectuer. Elle doit être « connectée ».

Aujourd’hui, les API utilisent souvent des clés d’API à cette fin. La clé est généralement comparée à un profil utilisateur afin de vérifier que l’appel est autorisé. Et ce, à chaque appel (dans une architecture sans état ). Plusieurs raisons peuvent motiver ce choix, notamment la possibilité de limiter le débit des appels. Un enjeu majeur. Le rapport State of APIs 2016 d’Apigee indiquait que 68 % des API avaient recours à la gestion des quotas (également appelée limitation de débit, comptage, etc.). Pour mettre en œuvre ce mécanisme technique, il faut d’abord savoir combien d’appels ont été effectués au cours de la dernière minute, heure ou journée. Ces données doivent donc être enregistrées dans un emplacement sécurisé (afin que les utilisateurs ne puissent pas les manipuler et tromper l’application pour qu’elle autorise davantage d’appels sur une période donnée).

En d’autres termes, les API peuvent fortement solliciter l’infrastructure d’authentification, car elles doivent vérifier le statut et les autorisations, et éventuellement appliquer une limitation du débit. Cela représente beaucoup de travail.

Pourtant, notre vision de l’architecture des applications, qui reste souvent traditionnelle, ne tient pas compte de l’incidence de ces appels supplémentaires sur la capacité. Ces appels supplémentaires de vérification et d’autorisation, même s’ils ne sont effectués que périodiquement pour « actualiser » une session, vont exercer une pression considérable sur l’infrastructure d’authentification — celle-là même qui prend en charge la connexion. C’est le même type de pression que nous avons observé lorsque la limite du nombre de connexions par utilisateur imposée par les navigateurs est passée de 2 à 8. Un seul utilisateur consommait alors 8 fois plus de ressources pour accéder à une application. De même, pour évaluer les besoins en capacité d’une application qui repose sur une autorisation à chaque appel d’API, il faut faire quelques calculs afin de déterminer combien de fois plus de ressources chaque utilisateur va consommer.

Ne pas le faire, c’est s’exposer à la colère d’enfants de 8 ans (et à celle de Lori, d’ailleurs) lorsque des services de connexion saturés sont tout ce qui les sépare du Pikachu qu’ils veulent désespérément attraper.

La mise à l’échelle de l’identification et de l’authentification est essentielle à la disponibilité

L’identité et la gestion des accès sont des services applicatifs essentiels. Depuis deux ans, nos enquêtes État des lieux de la fourniture d’applications montrent que leur importance ne cesse de croître et, sans trop en dévoiler, nos données de 2017 indiquent déjà une progression de la fédération des identités comme du contrôle d’accès aux applications. Et ce n’est pas seulement dû aux applications, mais aussi aux objets, ainsi qu’à la nécessité croissante de faire évoluer l’ensemble de l’infrastructure des services d’identité afin de prendre en charge davantage d’objets, d’utilisateurs et d’applications utilisant des API pour interagir avec les applications back-end.

La disponibilité est souvent évaluée uniquement en fonction de la durée d’indisponibilité. Si les serveurs étaient opérationnels et fonctionnaient correctement, ils étaient considérés comme disponibles. C’est une perspective de l’intérieur vers l’extérieur. Mais, comme pour la sécurité, nous devons inverser cette approche et l’envisager de l’extérieur vers l’intérieur. La capacité compte, et il ne suffit pas que les services soient simplement « opérationnels » et « disponibles ». Ils doivent l’être pour tous ceux qui souhaitent les utiliser. Cela implique de pouvoir évoluer aussi rapidement que vos scripts python peuvent s’exécuter.

Cela implique également de comprendre les relations entre les différents services back-end qui mettent concrètement en œuvre les fonctionnalités proposées par vos API. Les services de gestion des identités et des accès sont tout aussi essentiels à la disponibilité que l’application elle-même. Comme la sécurité, la disponibilité dépend de son maillon le plus faible. Et si vos services d’identité ne sont pas aussi évolutifs que le reste de votre application — voire davantage si votre modèle repose sur une authentification à chaque appel d’API —, la disponibilité deviendra un problème majeur, même si tous vos tableaux de bord affichent du « vert » en interne.

Car, de l’extérieur, nous voyons « rouge ». Au sens propre comme au sens figuré.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie