Json Web token - jwt vs. Traditional session login Authentication

Table des matières

1、Qu'est - ce queJWT

2、TraditionnelCookie-SessionCertification

2.1、Processus d'authentification de connexion

2.2、Inconvénients

2.3、springbootPour les projets monomères utilisant la traditionsessionRéaliser l'ouverture de session et l'authentification

3、Cookie-SessionCertification mise à jour----redisRéalisationsessionPartage

4、Basé surJWTCertification

4.1、Processus de certification

4.2、UtiliserJWTAvantages

---

1、Qu'est - ce queJWT

        JWTAbréviationsJSON Web Token,C'est - à - dire à traversJSONSous forme deWebJetons dans l'application,Utilisé pour assurer la sécurité de l'information entre les parties en tant queJSONTransfert d'objets.Le chiffrement des données peut également être effectué pendant la transmission des données、Signature et autres traitements connexes.Json web token (JWT), Est exécuté pour transmettre une déclaration entre les environnements d'application réseau basée surJSONNormes ouvertes pour.LetokenConçu pour être compact et sûr,Un point d'entrée unique pour les sites distribués（SSO）Scénario.JWTLes déclarations sont généralement utilisées pour transmettre des renseignements authentifiés sur l'identité de l'utilisateur entre le fournisseur d'identité et le fournisseur de services,Pour faciliter l'accès aux ressources du serveur de ressources,Il est également possible d'ajouter d'autres informations déclaratives nécessaires à la logique opérationnelle,LetokenPeut également être utilisé directement pour la certification,Peut également être chiffré.

Connexion unique:

        Le nom anglais d'un seul signe s'appelle：Single Sign On（AbréviationsSSO）.Avant, D'habitude, on Système unique, Toutes les fonctions sont sur le même système .Et puis,Nous voulons Utilisation rationnelle des ressources et réduction du couplage , Et donc un système unique Split Dans plusieurs sous - systèmes .

        Comme celui d'Ali Taobao et tmall , Il est clair que nous pouvons savoir que ce sont deux systèmes , Mais quand vous l'utilisez , Connecté à tmall , Taobao se connectera aussi automatiquement .En termes simples, Un seul signe est Dans plusieurs systèmes, L'utilisateur n'a besoin de se connecter qu'une seule fois , Les systèmes individuels peuvent sentir que l'utilisateur est connecté .

2、TraditionnelCookie-SessionCertification

2.1、Processus d'authentification de connexion

        1、 Le client envoie le mot de passe du compte au serveur pour authentification .

        2、 Après avoir vérifié que le mot de passe du compte est correct , Enregistrer les informations de base de l'utilisateur actuel dans la session en cours （session）Moyenne,Et vasessionid(JESSIONID)Retour au client.

        3、 Le client a sessionidPuis sauvegardez - le danscookieMoyenne, Et dans chaque demande ultérieure cookie Tous les deux. sessionid.sessionidéquivalent àkey,sessionéquivalent àvalue,Serveur viasessionidPour obtenirsession

        4、 Envoyé par le serveur selon le client sessionid Authentifier l'utilisateur actuel ,Déterminer la légalité.

2.2、Inconvénients

        1、Session: Chaque utilisateur est certifié par notre application,Toutes nos applications doivent enregistrer une fois sur le serveur,Pour faciliter l'authentification de la prochaine demande de l'utilisateur,En général,sessionTout est en mémoire,Et avec l'augmentation du nombre d'utilisateurs certifiés,Les frais généraux du serveur augmenteront considérablement.

        2、Extensibilité: Après l'authentification de l'utilisateur,Le serveur enregistre l'authentification,Si l'enregistrement authentifié est conservé en mémoire,.Cela signifie que l'utilisateur doit également demander sur ce serveur la prochaine fois qu'il demande,Pour avoir accès aux ressources autorisées,Pour les applications distribuées,En conséquence, la capacité de l'équilibreur de charge est limitée.Cela signifie également que la capacité d'expansion de l'application est limitée.Et si votre application back - end est un déploiement Multi - noeuds.Alors il fautRéalisationsessionMécanisme de partage.    Pas pratique pour les applications groupées.

       3、CSRF: Parce que c'est basé surcookiePour l'identification de l'utilisateur, cookieSi elle est interceptée,L'utilisateur sera vulnérable à la falsification de requêtes inter - stations

      4、Cookie-Session Seulement dans web Utilisation dans le scénario,Si oui APP Et alors?,APP Il n'y a pas de place pour cookie.
Aujourd'hui, les produits sont essentiellement disponibles en même temps web Fin et APP Deux modes d'utilisation, Certains produits n'ont même que APP

2.3、springbootPour les projets monomères utilisant la traditionsessionRéaliser l'ouverture de session et l'authentification

Connexion：

    // Formulaire de connexion envoyer la demande 
    @PostMapping("/login")
    public String login(User user, HttpSession session,Model model){
        // Omettre la requête de la base de données 
        if("luo".equals(user.getUsername())&&"123456".equals(user.getPassword()))
        {
            session.setAttribute("loginUser",user);
            return "redirect:/main.html";//Rediriger versmainPage
        }else {
            model.addAttribute("msg","Mauvais compte ou mot de passe");
            return "login";
        }
    }

      Une fois la connexion réussiesessionidRetour au navigateur client,Stocké danscookieMoyenne.

Intercepteur:

   @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //Login check Logic  AdoptionsessionidPour obtenirsession
        HttpSession session = request.getSession();
        //AccèssessionObjets stockés dans
        Object loginUser = session.getAttribute("loginUser");
        if(loginUser!=null)//Si ce n'est pas vide, Description l'utilisateur est déjà connecté 
            return true;//Connexion Release
        //Arrêtez!,Non connecté Aller à la page de connexion
        request.setAttribute("msg","Veuillez vous connecter.!");
        request.getRequestDispatcher("/login").forward(request,response);
        return false;
    }

       Après chaque demande initiale , Ils passent devant cet intercepteur . Par l'avant sessionid,Et à traverssessionidObtenir la correspondancesession.Et obtenirsessionObjets stockés dans 

Interface d'essai:

    @ResponseBody
    @GetMapping("/list")
    public List<User>  list(){
        //Interroger toutes les données
         List<User> list = userService.list();
         return list;
    }

Si aucune demande de connexion n'est faite, d'autres interfaces seront bloquées :Par exemplelistInterface

Accès à nouveau après connexion listInterface:

Connectez - vous d'abord:

         Une fois la connexion réussie, un JESSIONIDÀcookie- Oui..

Visite à nouveaulistInterface:

3、Cookie-SessionCertification mise à jour----redisRéalisationsessionPartage

Grâce à la tradition Cookie-Session La certification pose de nombreux problèmes , Cela pourrait transformer le schéma ci - dessus .
        1、Transformation Cookie Puisque Cookie Ça ne peut pas être APP Attendre d'être utilisé dans un autre navigateur ,Pas besoin. cookie Faire le stockage côté client , Utilisez une autre méthode .
        web Peut être utilisé dans local storage,APP Utilisation de la base de données client , Cela permet à la fois de réaliser des domaines croisés ,Et évité CSRF .

        2、 Le serveur n'est pas non plus enregistré Session C'est,Prends ça. Session L'information est sortie et stockée dans RedisMoyenne, Cela augmente la vitesse ,J'ai encore évité Session Problèmes de synchronisation;

Après modification, il est devenu le processus de certification suivant ：

1. L'utilisateur entre le nom d'utilisateur、 Un mot de passe ou un code de vérification SMS pour se connecter au système ;
2. Serveur authentifié , Stocker la structure de données construite avec les informations d'authentification dans Redis Moyenne,Et va key Valeur retournée au client;
3. Le client a reçu le retour key,Stocké dans local storage Ou une base de données locale ;
4. La prochaine fois que le client demande à nouveau ,Prends ça. key Valeur ajoutée à header Ou Dans le corps de la demande;
5. Serveur basé sur key,À Redis Obtenir des informations de certification;

Les deux diagrammes suivants illustrent le processus de première connexion et de non - première connexion, respectivement .

 

        Résoudre la tradition Cookie-Session Problèmes de méthode . Cette transformation exige que le développeur l'effectue lui - même dans le cadre du projet . Il faut du temps et de l'effort pour la transformer , Et il pourrait y avoir une fuite . 

4、Basé surJWTCertification

4.1、Processus de certification

         token Les informations de l'utilisateur peuvent être stockées dans ,Pas besoin d'être comme ça.session Ceci stocke les informations de l'utilisateur sur le serveur ,Mémoire occupée.

        1、Tout d'abord,,Passage frontalWebLe formulaire envoie son propre nom d'utilisateur et mot de passe à l'interface d'arrière - plan.Ce processus est généralement unHTTP POSTDemande.L'approche recommandée est la suivante:SSLTransmission chiffrée（httpsAccord）,Pour éviter de renifler des informations sensibles

        2、Après avoir vérifié avec succès le nom d'utilisateur et le mot de passe,De l'utilisateuridEt d'autres informationsJWT Payload（Charge）,Faites - le séparément de la têteBase64Signature après épissage du Code,Pour former unJWT(Token).Contient des informations sur l'utilisateur,Retour à l'avant ensemble, Pour ne pas avoir besoin de session De même, stockez les informations de l'utilisateur côté serveur , Il n'y aurait pas d'utilisation de la mémoire du serveur .

        3、L'arrière - planJWTLa chaîne est retournée à l'avant comme résultat de retour d'une connexion réussie.Le Front End peut enregistrer les résultats retournés danslocalStorageOusessionStorageAllez.,Supprimer l'enregistrement avant à la sortie de la connexionJWTC'est tout..

        4、À chaque demande, le Front EndJWTMettre dansHTTP HeaderDansAuthorizationBits.(Mettez - le surHeaderPeut être résoluXSSEtXSRFQuestions)

        5、Vérification de l'arrière - plan pour la présence,S'il y a vérificationJWTEfficacité.Par exemple,Vérifier si la signature est correcte;VérifiezTokenExpire - t - il?;VérifiezTokenSi le destinataire est lui - même（Facultatif）.

        6、Utilisation de l'arrière - plan après validationJWTInformations sur l'utilisateur contenues dans d'autres opérations logiques,Renvoie le résultat correspondant.

4.2、UtiliserJWTAvantages

        1、Simplicité(Compact): Peut passerURL,POSTParamètre ou dansHTTP headerEnvoyer,Parce que la quantité de données est petite,La vitesse de transmission est également rapide

        2、Auto - inclusion(Self-contained)：La charge utile contient les informations dont tous les utilisateurs ont besoin,Plusieurs requêtes dans la base de données ont été évitées

        3、Parce queTokenOui.JSONLa forme chiffrée est conservée dans le client,Alors...JWTEst multilingue,En principewebToutes les formes supportent

        4、Il n'est pas nécessaire d'enregistrer les informations de session sur le serveur,Particulièrement adapté aux micro - services distribués