« JWT SPA symfony exercice pratique » : différence entre les versions

Source: ? (perdue, disparue)

Chanter JWT pour l'authentification dans un SPA avec Symfony est très facile grâce à des bundles comme FOSUserBundle, LexikJWTAuthenticationBundle et JWTRefreshTokenBundle. Malheureusement, ils ne fournissent pas de sécurité contre les attaques XSS (ce qui, selon vous, n'est pas vraiment là). Dans cet article, je veux montrer comment nous pouvons améliorer une application Symfony en utilisant ces bundles pour empêcher les attaques XSS. Comme il est assez long, je vais le diviser en parties suivantes:

==== gesdinet_jwt_refresh_token.yaml ====

gesdinet_jwt_refresh_token:

     single_use: true

Cela rend évidemment le paramètre ttl_update: true inutile.

==== security.yaml ====

security:

   firewalls:

         path: /api/logout

         handlers: App\Service\Authentication\LogoutHandler

Dans le gestionnaire, nous injectons simplement la connexion à la base de données et supprimons les jetons. Le référentiel du bundle ne prend pas en charge la suppression de tous les jetons d'actualisation pour un utilisateur, mais vous pouvez également étendre l'implémentation RefreshTokenManager, ajouter une méthode de référentiel et l'injecter ici à la place.

==== LogoutHandler ====

     <?php

     declare(strict_types=1);

         }

     }

=== Ajouter un cookie à l'authentification JWT ===

===== generateSecurityCookieHash =====

     private function generateSecurityCookieHash(User $user, RefreshTokenInterface $refreshToken): string

     {

         );

     }

Comme nous allons avoir besoin de cela et de quelques méthodes supplémentaires, nous allons créer un service central appelé AuthenticationService.

===== AuthenticationService =====

     <?php

     declare(strict_types=1);

         }

     }

Nous utilisons la même date d'expiration pour le cookie que pour le jeton d'actualisation et le marquons comme http uniquement.

===== security.yaml =====

security:

   firewalls:

         check_path: /api/login

         success_handler: App\Service\Authentication\LoginSuccessHandler

===== LoginSuccessHandler =====

     declare(strict_types=1);

     namespace App\Service\Authentication;

         }

     }

Nous allons maintenant obtenir un cookie de sécurité que nous vous enverrons à chaque demande et qui n'est pas accessible par Javascript. Mais ce n'est pas évalué pour le moment, alors faisons-le.

===== security.yaml =====

security:

   firewalls:

         authenticators:

           - App\Service\Authentication\JWTAndSecurityCookieAuthenticator

===== JWTAndSecurityCookieAuthenticator =====

     declare(strict_types=1);

     namespace App\Service\Authentication;

         }

     }

===== routes.yaml =====

api_refresh_token:

     path: '/api/token/refresh'

     defaults: { _controller: gesdinet.jwtrefreshtoken:refresh }

     methods: [POST]  

*Nous utilisons le suivant

api_refresh_token:

     path: '/api/token/refresh'

     defaults: { _controller: App\Service\Authentication\RefreshTokenSecurityCookieService:refresh }

     methods: [POST]

La copie complète est annotée avec les espaces où je place la validation du cookie et la création du cookie après l'ajout du nouveau jeton d'actualisation.

===== RefreshTokenSecurityCookieService =====

     declare(strict_types=1);

     namespace App\Service\Authentication;

         }

     }

De cette façon, lorsqu'un nouveau JWT est demandé, le jeton d'actualisation et le cookie sont validés. Un nouveau cookie est également émis ici, car chaque fois que le JWT est demandé, un nouveau jeton d'actualisation est émis et l'ancien cookie a donc été invalidé.