Un article expliquant en détail comment implémenter l'authentification par microservice

Cet article vous apporte des connaissances pertinentes sur l'authentification. Il présente principalement les idées de mise en œuvre de l'authentification dans les microservices ? Existe-t-il une bonne solution pour y parvenir ? Jetons-y un coup d'œil ensemble, j'espère que cela sera utile à tout le monde.

Certains amis ont récemment posé cette question sur WeChat, alors je suis venu discuter avec vous. Cet article parle principalement d'idées avec des amis sans écrire de code, vous devriez pouvoir le combiner. pour écrire le code de cet article par vous-même. Bien sûr, les idées ne sont que ma propre expérience pratique et ne constituent peut-être pas la solution la plus parfaite. Les amis sont invités à en discuter dans les commentaires.

1. Authentification et autorisation

Tout d'abord, les amis savent que que nous étudions Shiro ou Spring Security, quelles que soient les fonctions, les principales sont au nombre de deux :

• Authentification

• Autorisation

Par conséquent, lorsque nous traitons des problèmes d’authentification dans les microservices, nous pouvons également considérer ces deux aspects.

1.1 Authentification

L'authentification, pour parler franchement, signifie se connecter. Le login Web traditionnel est une solution Cookie+Session, qui s'appuie sur la mémoire locale du serveur, en raison du grand nombre de services, cette solution n'est évidemment plus adaptée.

Certains amis peuvent dire d'utiliser Redis+SpringSession pour le partage de session. C'est une solution, mais ce n'est pas la meilleure solution car les performances et l'évolutivité de cette solution sont relativement médiocres.

Par conséquent, il est recommandé d'utiliser des jetons pour l'authentification dans les microservices. Vous pouvez choisir des jetons JWT, qui sont également une solution couramment utilisée à l'heure actuelle. Cependant, les amis qui connaissent JWT savent que la connexion sans état pure ne peut pas permettre la déconnexion, ce qui est très gênant. Par conséquent, dans les applications pratiques, la simple utilisation de JWT n'est généralement pas suffisante. Généralement, il est nécessaire de le combiner avec Redis pour convertir le JWT généré. caractères. La chaîne est également enregistrée sur Redis et le délai d'expiration est défini. Lorsque vous déterminez si l'utilisateur est connecté, vous devez d'abord vérifier si la chaîne JWT existe sur Redis, puis analyser la chaîne JWT. peut être analysé avec succès, il n'y aura pas de problème, s'il ne peut pas être analysé avec succès, cela signifie que le jeton est illégal.

Cette façon de mélanger la connexion avec état et la connexion sans état peut sembler un peu quelconque, mais pour l'instant, cette méthode de compromis est considérée comme une solution réalisable.

En fait, la solution ci-dessus, pour parler franchement, n'est pas différente du traditionnel Cookie+Session. Les idées sont presque entièrement copiées : la traditionnelle Session est remplacée par le traditionnel jsessionId qui fait la navette entre le serveur et le. Le navigateur est une chaîne JWT à la place ; le jsessionId traditionnel est transmis via Cookie, et le JWT actuel est défini manuellement par le développeur et transmis via l'en-tête de la demande. La session traditionnelle peut être automatiquement renouvelée, mais maintenant JWT est renouvelé manuellement et chaque demande atteint ; le serveur. Le moment venu, vérifiez le délai d'expiration du jeton sur Redis. S'il est sur le point d'expirer, réinitialisez-le. Tout le reste sera exactement le même.

C'est votre choix de programme de certification.

1.2 Autorisation

L'autorisation dans les microservices peut également être effectuée à l'aide du framework Shiro ou Spring Security, ce qui évite des problèmes. Étant donné que la pile technologique de microservices est un produit de la famille Spring, il est recommandé à chacun de choisir d'abord Spring Security en termes de cadre d'autorisation (si des amis ne sont pas familiers avec Spring Security, vous pouvez répondre à ss en arrière-plan de WeChat). compte officiel, il y a des tutoriels) .

Bien sûr, si vous pensez que Spring Security est plus compliqué et que vous souhaitez le faire vous-même, vous pouvez le faire. Si vous le faites vous-même, vous pouvez également utiliser l'idée de​​Spring Security. L'un des projets récents de Song Ge ressemble à ceci :

Une fois que la demande atteint le microservice, recherchez d'abord diverses informations sur l'utilisateur actuel, notamment les rôles et les autorisations détenus par l'utilisateur actuel. Attendez les informations, puis stockez-les dans l'objet ThreadLocal lié au thread actuel. D'autre part, personnalisez les annotations d'autorisation et les annotations de rôle, analysez ces annotations par aspects et vérifiez si l'utilisateur actuel dispose des rôles/autorisations requis, etc.

Bien sûr, si vous utilisez Spring Security, vous n'avez pas besoin d'annotations personnalisées pour ce qui précède. Vous pouvez simplement utiliser celles fournies avec Spring Security. Vous pouvez également bénéficier de fonctions de sécurité plus riches dans Spring Security.

2. Service d'authentification

Alors, où se font l'authentification et l'autorisation ?

Parlons d'abord de l'authentification. L'authentification peut être simplement divisée en deux étapes :

• Connexion

• Vérification

2.1 Connexion

De manière générale, nous pouvons créer un service d'authentification distinct pour la connexion. Lorsque la demande de connexion atteint la passerelle, nous la transmettons au service d'authentification pour terminer l'opération d'authentification.

Dans le service d'authentification, nous vérifions si le nom d'utilisateur/mot de passe est OK et si le statut de l'utilisateur est OK. S'il n'y a pas de problème, générons une chaîne JWT, stockons les données dans Redis, puis renvoyons la chaîne JWT.

Si le système dispose d'une fonction d'enregistrement, la fonction d'enregistrement est également complétée sur ce microservice.

2.2 Vérification

La vérification fait référence à la vérification si l'utilisateur s'est connecté lorsque chaque demande arrive.

Bien sûr, vous pouvez le faire avec la version 2.1, mais Brother Song ne le recommande pas. Le problème est que s'il s'agit d'une demande de création d'une commande, cette demande est initialement transmise au service de commande via la passerelle. Cependant, à ce stade, le service de la section 2.1 doit être appelé sur la passerelle pour vérifier la connexion. Il n'y a pas de problème, il sera transmis à. En termes de service de commande, cela prend évidemment beaucoup de temps et n'est pas raisonnable.

Une meilleure façon est de vérifier directement si le token demandé est légal sur la passerelle. Cette vérification en elle-même est relativement simple. Pour vérifier si le token est légal, il suffit de vérifier si le token existe sur Redis, et ce aussi longtemps. comme le jeton JWT peut être analysé en douceur, cette opération peut être effectuée sur la passerelle.

En prenant Gateway comme exemple, nous pouvons personnaliser le filtre global et vérifier le jeton de chaque demande dans le filtre global. Si la vérification réussit, la demande sera transmise, sinon elle ne sera pas transmise.

Après avoir réussi la vérification, après transfert au microservice spécifique, nous pouvons mettre l'identifiant d'utilisateur et le nom d'utilisateur analysés ainsi que d'autres informations dans l'en-tête de la demande, puis les transmettre, de sorte qu'après avoir atteint chaque microservice spécifique, nous sachions qui a envoyé cette demande et les rôles/autorisations dont dispose cette personne, afin de faciliter la prochaine étape de vérification des autorisations.

Ce que Song Ge a fait, c'est définir un module public. Tous les microservices dépendent de ce module public. Un intercepteur est défini dans ce module public, qui interceptera chaque requête, retirera l'ID utilisateur de l'en-tête de la requête, puis récupérera. informations utilisateur spécifiques de Redis et stockez-les dans ThreadLocal. Dans les appels de méthode suivants, si vous devez déterminer si l'utilisateur dispose d'une certaine autorisation, vous pouvez l'obtenir via ThreadLocal.

C'est à peu près un tel processus.

3. Service d'autorisation

L'autorisation ne peut pas être effectuée sur la passerelle, elle doit quand même être effectuée sur chaque microservice.

On peut grossièrement diviser l'autorisation sur les microservices en deux catégories :

• Requêtes envoyées par le front end (requêtes externes).

• Demandes envoyées depuis d'autres microservices (demandes internes).

3.1 Requêtes externes

Pour les requêtes externes, traitez-les simplement selon la vérification normale des autorisations ou en utilisant des frameworks tels que Spring Security sont acceptables. S'il s'agit d'une annotation personnalisée, combinez-la simplement avec AOP. aspects pour gérer vous-même les annotations d'autorisation. Bien sûr, ces fonctions sont fondamentalement requises par chaque microservice, elles peuvent donc être extraites dans un module public et utilisées dans différents microservices.

3.2 Demandes internes

Pour les demandes internes, l'authentification n'est normalement pas requise et les demandes internes peuvent être traitées directement. Le problème est que si OpenFeign est utilisé, les données sont exposées via l'interface. Sans authentification, nous nous soucierons des requêtes externes appelant cette interface. Pour ce problème, nous pouvons également personnaliser les annotations + AOP, puis demander en interne lors de l'appel. ajoutez un champ d'en-tête supplémentaire pour le distinguer.

Bien sûr, lorsque les requêtes internes atteignent les microservices, elles doivent également être authentifiées, tout comme lorsque les requêtes sont transmises de la passerelle vers chaque microservice spécifique, l'authentification est requise. Mais évidemment, nous n'avons pas besoin d'utiliser OpenFeign pour en appeler d'autres. choses à chaque fois. Lors du service, un tas d'informations d'authentification sont transmises. Nous pouvons définir un intercepteur de requêtes OpenFeign en implémentant l'interface feign.RequestInterceptor dans l'intercepteur, les informations d'en-tête de requête sont définies de manière uniforme pour les requêtes OpenFeign.

D'accord, concernant l'authentification dans les microservices, c'est ainsi que nous procédons actuellement. Les amis sont invités à laisser un message et à en discuter ensemble.

Apprentissage recommandé : "Tutoriel vidéo du mini programme" "Tutoriel vidéo Java"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!