Le nouveau AAA : API, authentification et disponibilité

Vous avez peut-être compris que oui, je fais partie de ces personnes qui jouent à Pokémon Go. Ou, comme c’est souvent le cas ces derniers temps, ne pas jouer à Pokémon Go. C'est mauvais, car cela signifie également que notre plus jeune ne joue pas, car il s'avère que nous utilisons tous les deux des comptes Pokémon Trainer Club (PTC) pour jouer, pas des comptes Google, et nous ne pouvons pas y accéder.

C’est important, car alors que nous sommes tous les deux frustrés par notre incapacité à « nous authentifier » et à nous connecter pour jouer, mon mari a choisi d’utiliser son compte Google et, eh bien, il n’a pas les mêmes problèmes.

Cela m’a amené à approfondir certaines préoccupations techniques qui devraient vraiment trouver un écho auprès de toutes les entreprises, quelle que soit l’application qu’elles lancent. Cette préoccupation tourne autour des nouveaux AAA – API, authentification et disponibilité.

Il est intéressant de noter que cette quête a commencé lorsque je lisais un article dans Forbes sur le suivi des Pokémon dans Pokémon Go. Oui, Forbes. C'est aussi gros que ça. Dans tous les cas, cela a donné lieu à un autre article, puis à un autre, l'un d'eux spéculant que la raison pour laquelle le suivi était (au moins initialement) interrompu était due à une mise à jour du jeu dans laquelle une clé API avait été par inadvertance laissée de côté dans les appels de suivi renvoyés aux serveurs de Niantic.

Que ce soit le cas ou non, un tel faux pas pourrait effectivement briser les API. Mais la chose sur laquelle je revenais sans cesse était que si je ne pouvais pas me connecter à mon compte PTC et jouer, comment pouvais-je passer à mon compte Google et jouer facilement ?

La connexion d'authentification API

Eh bien, cela m'a fait fouiller sur GitHub et fouiller dans les API de Pokémon Go (je préfère Java , mais Python existe aussi, devenez fou) et cela a finalement fait s'allumer la lumière « aha ». Voyez, presque tous les appels d’API dans ces référentiels gèrent la même exception : Exception d'échec de connexion . 

En d’autres termes, même un simple appel pour trouver des Pokémon à proximité peut entraîner une LoginFailedException .

Ce qui n’est pas vraiment surprenant. Voyez, les applications Web monolithiques suivent souvent les utilisateurs authentifiés via des sessions, ce qui signifie souvent un cookie contenant un identifiant de session ou un autre jeton que l'application vérifie avant de faire quoi que ce soit d'autre (c'est une architecture avec état , pour ceux qui suivent). Les API ne sont pas si différentes, dans la mesure où chaque appel d'API doit disposer d'un moyen de garantir que l'application appelante (l'utilisateur) est effectivement autorisée à effectuer l'appel en premier lieu. Ils doivent être « connectés ».

Désormais, les API utilisent souvent des clés API pour y parvenir. La clé est généralement vérifiée par rapport au profil d'un utilisateur pour garantir que l'appel est autorisé. Chaque appel (dans une architecture sans état ). Plusieurs raisons justifient une telle décision, notamment la possibilité de limiter le débit des appels. Ce qui est une affaire importante. État des API 2016 selon Apigee Le rapport a noté que 68 % des API profitaient de la gestion des quotas (également connue sous le nom de limitation de débit, de comptage, etc.)  Pour réaliser cette astuce technique, il faut d'abord savoir combien d'appels ont été effectués au cours de la dernière minute/heure/jour, et il faut donc le suivre dans un endroit sûr (afin que les utilisateurs ne puissent pas le manipuler et tromper l'application pour qu'elle autorise plus d'appels par période).

En d’autres termes, les API peuvent être très exigeantes pour l’infrastructure d’authentification, car elles doivent vérifier le statut, l’autorisation et éventuellement appliquer une limitation de débit. C'est beaucoup de travail.

Pourtant, nos mentalités en matière d’architecture d’application, souvent encore traditionnelles, ne prennent pas en compte l’impact de ces appels supplémentaires sur la capacité. Ces appels supplémentaires de vérification et d’autorisation, même s’ils sont effectués de manière périodique pour « rafraîchir » une session, vont exercer une pression considérable sur l’infrastructure d’authentification. La même infrastructure d’authentification qui prend en charge la connexion. C’est le même type de stress que nous avons constaté lorsque les limites du navigateur sur les connexions par utilisateur ont été augmentées de 2 à 8. Un seul utilisateur consommait désormais 8 fois plus de ressources pour accéder à une application. De même, lorsque l’on considère les besoins en capacité d’une application qui s’appuie sur une autorisation par appel d’API, il faut faire quelques calculs et déterminer combien de X supplémentaires cet utilisateur individuel va consommer.

Ne pas le faire conduit à, eh bien, la colère des enfants de 8 ans (et de Loris aussi, d’ailleurs) lorsque des services de connexion surchargés sont ce qui se dresse entre eux et ce Pikachu qu’ils veulent désespérément attraper.

Mise à l'échelle de l'ID et A critique pour la disponibilité

L'identité et l'accès sont des services d'application essentiels . Nous avons constaté une augmentation de leur importance dans nos enquêtes sur l’état de la distribution des applications au cours des deux dernières années, et sans trop en dévoiler, nous constatons déjà des augmentations dans nos données de 2017 pour la fédération d’identité et le contrôle d’accès aux applications. Et ce n’est pas seulement à cause des applications, c’est aussi à cause des objets , et du besoin croissant de faire évoluer l’ensemble de l’infrastructure des services d’identité pour prendre en charge davantage de choses, davantage d’utilisateurs, davantage d’applications utilisant des API pour interagir avec les applications back-end.

La disponibilité est souvent basée uniquement sur une mesure de temps d’arrêt. Si les serveurs sont opérationnels et fonctionnent correctement, ils sont disponibles. C’est une perspective de l’intérieur vers l’extérieur. Mais comme pour la sécurité, nous devons inverser cette mesure et la considérer de l’extérieur vers l’intérieur. La capacité compte, et le simple fait d’être « opérationnel » et « disponible » ne suffit pas. Les services doivent être « opérationnels » et « disponibles » pour tous ceux qui souhaitent les consommer. Cela signifie évoluer aussi vite que vos scripts Python peuvent s'exécuter.

Cela signifie également comprendre la relation entre les différents services back-end qui implémentent réellement les fonctionnalités présentées par vos API. Les services d’identité et d’accès sont aussi essentiels à la disponibilité que l’application elle-même. La disponibilité, comme la sécurité, n’est aussi bonne que son maillon le plus faible. Et si vos services d’identité ne sont pas aussi évolutifs (ou plus évolutifs si votre modèle repose sur une authentification par appel d’API) que le reste de votre application, vous constaterez que la disponibilité est un problème important, même si tous vos tableaux de bord affichent « vert » à l’intérieur.

Parce que de l’extérieur, on voit du « rouge ». Au sens propre comme au sens figuré.