Plongée approfondie dans l'authentification des Microservices

Qu'est-ce qu'un service d'authentification

L'authentification consiste à vérifier l'identité d'un utilisateur pour lui accorder l'accès et les permissions nécessaires pour utiliser le système. Le service qui fournit cette fonction est le service d'authentification. Dans une application logicielle monolithique traditionnelle, tout cela se déroule au sein de la même application, mais dans une architecture de microservices, le système est composé de plusieurs services. Chaque microservice a ses propres tâches dans une telle architecture, donc implémenter le processus d'autorisation et d'authentification séparément pour chaque microservice ne fonctionne pas complètement.

Cet article comparera l'authentification traditionnelle et l'authentification des microservices. Il démontrera les changements dans l'authentification apportés par les changements dans l'architecture. Enfin, nous analyserons les différents services d'authentification dans l'architecture des microservices ainsi que leurs avantages et inconvénients dans leurs implémentations.

Service d'authentification dans l'architecture traditionnelle

Au début, lorsque les entreprises développaient des services, toutes les fonctions étaient implémentées dans la même application. Nous appelons ce modèle "monolithique" pour le distinguer de l'architecture "microservices" plus courante aujourd'hui.

Une application monolithique est constituée d'une seule unité indivisible. Elle est généralement développée indépendamment par des lignes métier distinctes et combinée dans le même environnement lors du déploiement. Tous ces éléments sont étroitement intégrés pour fournir toutes les fonctionnalités dans une seule unité. Cette unité possède toutes les ressources nécessaires. L'avantage d'une application monolithique est qu'elle est facile à déployer et à itérer. Elle convient aux entreprises plus indépendantes avec moins de lignes métier.

À mesure que les activités développées par les entreprises deviennent de plus en plus complexes, nous constatons que les services uniques ne peuvent plus répondre aux besoins d'itération rapide dans la vie réelle. Nous devons diviser ce système géant et nous assurer que les appels entre les fonctions existantes peuvent être effectués normalement. Pour résoudre ce problème, ESB (Enterprise Service Bus) est apparu.

Le "bus de services d'entreprise" est un pipeline reliant divers services d'entreprise. L'existence de l'ESB est d'intégrer différents services avec différents protocoles. L'ESB fournit des services tels que la traduction et le routage des requêtes clients, permettant ainsi à différents services de s'interconnecter facilement. Comme vous pouvez le deviner d'après le nom, son concept s'inspire du modèle de communication dans le principe de composition des ordinateurs - le bus, tous les systèmes qui ont besoin de communiquer avec des systèmes externes se connectent à l'ESB. Vous pouvez utiliser le système existant pour construire un nouveau système distribué hétérogène faiblement couplé.

L'ESB a traduit et routé les requêtes afin que différents services puissent communiquer entre eux. La méthode traditionnelle d'invocation de service ESB est que chaque appelant doit d'abord être routé via l'ESB central vers le service.

Architecture monolithique

L'authentification des utilisateurs et la gestion des sessions sont relativement simples : l'authentification et l'autorisation se déroulent dans la même application, généralement en utilisant un schéma d'authentification basé sur les sessions. Une fois authentifié, une session est créée et stockée sur le serveur. Tout composant peut y accéder et l'utiliser pour notifier et autoriser les requêtes ultérieures. L'ID de session est envoyé au client et utilisé pour associer toutes les requêtes ultérieures à la session en cours.

Architecture ESB

Dans l'architecture ESB, tous les processus entre les services sont traités via le bus ESB. Puisque l'architecture ESB dérive de l'architecture monolithique, la méthode d'authentification n'a pas changé par rapport à l'architecture monolithique.

Service d'authentification dans l'architecture des microservices

La migration d'une architecture monolithique vers une architecture de microservices présente de nombreux avantages. Cependant, en tant qu'architecture distribuée, l'architecture de microservices a une surface d'attaque plus large, ce qui rend plus difficile le partage du contexte utilisateur. Par conséquent, différents services d'authentification sont nécessaires dans l'architecture des microservices pour répondre à des défis de sécurité plus importants.

Nous pouvons diviser les services d'authentification dans l'architecture des microservices en trois catégories suivantes :

1. Implémenter l'authentification sur chaque microservice
2. Implémenter l'authentification via un service d'authentification
3. Implémenter l'authentification via la passerelle API

Chaque approche a ses propres avantages et inconvénients spécifiques.

Implémenter l'authentification sur chaque microservice

Puisque chaque microservice est séparé de l'architecture monolithique, une transition naturelle pour implémenter l'authentification est que chaque microservice l'implémente lui-même.

Chaque microservice doit implémenter ses propres garanties de sécurité, appliquées à chaque point d'entrée. Cette approche permet aux équipes de microservices de prendre des décisions autonomes sur la mise en œuvre de leurs solutions de sécurité. Cependant, cette approche présente plusieurs inconvénients :

• La logique de sécurité doit être implémentée à plusieurs reprises dans chaque microservice. Cela entraîne une duplication de code entre les services.
• Cela distrait l'équipe de développement de se concentrer sur leur service principal.
• Chaque microservice dépend des données d'authentification utilisateur qu'il ne possède pas.
• Difficile à maintenir et à surveiller.

Une option pour améliorer cette solution est d'utiliser une bibliothèque d'authentification partagée chargée sur chaque microservice. Cela évitera la duplication de code, et l'équipe de développement se concentrera uniquement sur son domaine métier. Cependant, il reste des lacunes que cette amélioration ne peut pas résoudre. Parce que la bibliothèque d'authentification partagée doit toujours avoir les données d'identité utilisateur correspondantes, il est également nécessaire de s'assurer que chaque microservice utilise la même version de la bibliothèque d'authentification. La bibliothèque d'authentification partagée ressemble plus au résultat d'une mauvaise division des services.

Avantages : mise en œuvre rapide, forte indépendance

Inconvénients : duplication de code entre les services ; violation du principe de responsabilité unique ; difficulté de maintenance

Implémenter l'authentification via un service d'authentification

Puisqu'il est difficile pour chaque microservice d'implémenter l'authentification par lui-même, et que l'utilisation d'une bibliothèque d'authentification partagée va à l'encontre de l'intention initiale de la division des microservices, peut-on améliorer la bibliothèque d'authentification partagée en un service d'authentification dédié ?

Dans ce cas, tous les accès sont contrôlés par le même service, similaire à la fonction d'authentification dans une application monolithique. Chaque service métier doit envoyer une demande d'autorisation séparée au module de contrôle d'accès lors de l'exécution d'une opération.

Cependant, cette approche ralentit le service et augmente l'interconnexion entre les services. Et chaque microservice dépendra de ce service d'authentification "unique". Il est vulnérable à un point de défaillance unique et à une réaction en chaîne qui cause des dommages supplémentaires.

Avantages : Chaque microservice a une responsabilité unique, et l'authentification est centralisée

Inconvénients : Point de défaillance unique ; augmentation de la latence des requêtes

Implémenter l'authentification via la passerelle API

Lors de la migration vers une architecture de microservices, une question qui doit être résolue est comment les microservices communiquent entre eux. L'ESB mentionné ci-dessus est une approche, mais plus couramment, une passerelle API est utilisée. La passerelle API est un point d'entrée unique pour toutes les requêtes. Elle offre une flexibilité en agissant comme une interface centrale pour consommer ces microservices. Un microservice qui a besoin d'accéder à d'autres microservices (à partir de maintenant, nous l'appellerons "client" pour le distinguer du microservice qu'il accède) n'a pas d'accès direct aux services, mais envoie la requête à la passerelle API responsable de router le client vers le service en amont.

Puisque toutes les requêtes doivent d'abord passer par la passerelle API, c'est un excellent candidat pour appliquer les problèmes d'authentification. Cela réduit la latence (appels aux services d'authentification) et garantit que le processus d'authentification est cohérent dans toute l'application.

Par exemple, en utilisant le plugin jwt-auth d'APISIX, nous pouvons implémenter l'authentification sur la passerelle.

1. Nous devons configurer plusieurs informations d'identité utilisateur (nom, clé, etc.) sur APISIX.
2. Selon la clé de l'utilisateur donnée, initier une demande de signature à APISIX pour obtenir le jeton JWT de l'utilisateur.
3. Ensuite, lorsque le client a besoin d'accéder à un service en amont, il apporte le jeton JWT, et APISIX agit comme la passerelle API pour proxifier cet accès.
4. Enfin, APISIX effectuera l'opération d'authentification en utilisant le jeton JWT.

Bien sûr, tout a des avantages et des inconvénients, et aucune technologie n'est complète sans inconvénients. Utiliser une passerelle API pour compléter l'authentification présente encore quelques problèmes. Résoudre ce problème sur la passerelle est moins sécurisé que de compléter l'authentification au sein de chaque microservice. Par exemple, si la passerelle API est compromise, elle exposera tous les microservices derrière elle. Mais le risque est relatif. Par rapport au service d'authentification unique, le problème de l'utilisation d'une passerelle API est mineur.

Avantages : Protection efficace des microservices backend ; les microservices n'ont pas besoin de gérer de logique d'authentification

Inconvénient : Point de défaillance unique

Résumé

Dans différents scénarios, nous aurons besoin de différents schémas d'authentification. Dans une application monolithique, l'authentification se déroule dans la même application, et le serveur sauvegarde toutes les sessions. À l'ère des microservices, les applications monolithiques ont évolué en services distribués, et les méthodes d'authentification traditionnelles ne s'appliquent plus. Dans l'architecture des microservices, nous avons trois méthodes d'authentification à choisir :

1. Implémenter l'authentification sur chaque microservice
2. Implémenter l'authentification via un service d'authentification
3. Implémenter l'authentification via la passerelle API

Chaque option a ses propres avantages et inconvénients, qui doivent être analysés en détail selon les circonstances.