Résolution de la gestion des jetons d'actualisation JWT dans Angular avec HttpInterceptor

Assurer une actualisation transparente de JWT dans les intercepteurs angulaires

Dans une application Web avec des sessions utilisateur sécurisées, la gestion efficace des jetons JWT de courte durée est cruciale pour une expérience utilisateur ininterrompue. Lorsque les jetons expirent, les utilisateurs rencontrent souvent des problèmes tels que le fait d'être obligés de se reconnecter, ce qui peut être frustrant et perturber l'engagement des utilisateurs. Pour résoudre ce problème, les développeurs implémentent généralement l'actualisation automatique des jetons à l'aide d'un intercepteur angulaire pour gérer les sessions expirées. 🕰️

Cette approche consiste à intercepter les requêtes HTTP, à détecter les erreurs 401 (requêtes non autorisées), puis à appeler un processus d'actualisation pour obtenir un nouveau jeton. Cependant, des problèmes peuvent survenir pour garantir que le jeton ou le cookie mis à jour est appliqué aux requêtes réessayées. Si le nouveau jeton ne se propage pas correctement, la nouvelle tentative peut échouer, laissant les utilisateurs avec la même erreur d'autorisation et potentiellement perturbant les flux de travail de l'application.

Dans ce guide, nous présenterons une implémentation pratique de ce modèle d'intercepteur. Nous verrons comment détecter les erreurs, actualiser les jetons et confirmer que les demandes réessayent avec une autorisation valide. Cette approche minimise les interruptions tout en vous donnant le contrôle du processus de renouvellement de session.

À la fin, vous découvrirez comment résoudre les pièges courants, comme la gestion des cookies HttpOnly et la gestion des séquences d'actualisation lors de volumes de requêtes élevés. Cette méthode garantit que votre application peut maintenir une session utilisateur sécurisée et fluide sans connexions constantes. 🔒

Garantir une authentification JWT fiable avec des intercepteurs angulaires

Dans l'exemple ci-dessus, l'intercepteur est conçu pour actualiser automatiquement un jeton JWT de courte durée chaque fois qu'une erreur 401 est rencontrée. Ce type de configuration est essentiel dans les applications contenant des données sensibles, où le maintien de la sécurité des sessions est essentiel, mais où l'expérience utilisateur ne doit pas être interrompue. L'intercepteur détecte l'erreur 401 (non autorisé) et lance une demande de jeton d'actualisation pour renouveler la session sans exiger que l'utilisateur se réauthentifie. Ce processus est déclenché par la fonction catchError, qui permet la gestion des erreurs au sein d'un pipeline observable. Ici, toute erreur HTTP, en particulier un 401, signale que le jeton a probablement expiré et lance le processus d'actualisation.

La fonction switchMap est un autre élément central ici ; il crée un nouveau flux observable pour la demande actualisée, remplaçant l'ancien observable sans annuler l'intégralité du flux. Après l'actualisation, il réessaye la demande d'origine, en s'assurant que le nouveau jeton est appliqué. En passant de l'ancien observable à un nouveau, l'intercepteur peut effectuer le renouvellement du jeton de manière transparente et non bloquante. Cette technique est particulièrement utile lorsque vous travaillez avec des applications en temps réel, car elle réduit les interruptions dans les interactions des utilisateurs tout en maintenant une authentification sécurisée. Par exemple, un utilisateur parcourant un tableau de bord financier sécurisé ne sera pas redirigé ou déconnecté inutilement ; au lieu de cela, le nouveau jeton est acquis et appliqué en arrière-plan. 🔄

De plus, le BehaviorSubject joue un rôle crucial en gérant l'état du processus d'actualisation. Cet utilitaire RxJS peut conserver la dernière valeur émise, ce qui est particulièrement utile lorsque plusieurs requêtes rencontrent une erreur 401 en même temps. Au lieu de déclencher plusieurs actualisations, l'intercepteur ne lance qu'une seule actualisation de jeton et toutes les autres demandes sont mises en file d'attente pour attendre ce renouvellement de jeton unique. L'utilisation de BehaviorSubject avec switchMap permet de garantir que si une requête déclenche l'actualisation, toutes les autres requêtes nécessitant le nouveau jeton utiliseront les informations d'identification mises à jour sans provoquer d'appels d'actualisation répétés. Cette fonctionnalité est extrêmement utile dans les cas où les utilisateurs peuvent avoir plusieurs onglets ouverts ou où l'application gère plusieurs appels réseau simultanés, économisant ainsi des ressources et évitant une charge excessive du serveur.

Tester cette logique d'intercepteur est également essentiel pour garantir qu'il fonctionne dans différents scénarios, c'est pourquoi nous incluons le HttpTestingController. Cet outil de test angulaire nous permet de simuler et de tester les réponses HTTP, comme le statut 401 non autorisé, dans un environnement contrôlé. Grâce à flush, une méthode fournie par HttpTestingController, les développeurs peuvent simuler des réponses d'erreur réelles et vérifier que l'intercepteur se comporte comme prévu. Cette approche de test nous permet d'affiner la façon dont la logique d'actualisation gère divers cas avant de déployer l'application. Grâce à ces méthodes, l'intercepteur préserve non seulement la session en toute sécurité, mais offre également une expérience plus transparente et plus stable aux utilisateurs naviguant dans l'application. 👩‍💻

import { Injectable } from '@angular/core';
import { HttpEvent, HttpInterceptor, HttpHandler, HttpRequest, HttpErrorResponse } from '@angular/common/http';
import { catchError, switchMap } from 'rxjs/operators';
import { Observable, throwError, BehaviorSubject } from 'rxjs';
import { AuthService } from './auth.service';
import { Router } from '@angular/router';
@Injectable()
export class JwtInterceptor implements HttpInterceptor {
  private refreshTokenInProgress$ = new BehaviorSubject<boolean>(false);
  constructor(private authService: AuthService, private router: Router) {}
  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    req = req.clone({ withCredentials: true });
    return next.handle(req).pipe(
      catchError((error: HttpErrorResponse) => {
        if (error.status === 401) {
          return this.handle401Error(req, next);
        }
        return throwError(() => error);
      })
    );
  }
  private handle401Error(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (!this.refreshTokenInProgress$.getValue()) {
      this.refreshTokenInProgress$.next(true);
      return this.authService.refreshToken().pipe(
        switchMap(() => {
          this.refreshTokenInProgress$.next(false);
          return next.handle(req.clone({ withCredentials: true }));
        }),
        catchError((error) => {
          this.refreshTokenInProgress$.next(false);
          this.authService.logout();
          this.router.navigate(['/login'], { queryParams: { returnUrl: req.url } });
          return throwError(() => error);
        })
      );
    }
    return this.refreshTokenInProgress$.pipe(
      switchMap(() => next.handle(req.clone({ withCredentials: true })))
    );
  }
}

import { TestBed } from '@angular/core/testing';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { JwtInterceptor } from './jwt.interceptor';
import { HTTP_INTERCEPTORS, HttpClient } from '@angular/common/http';
import { AuthService } from './auth.service';
describe('JwtInterceptor', () => {
  let httpMock: HttpTestingController;
  let authServiceSpy: jasmine.SpyObj<AuthService>;
  let httpClient: HttpClient;
  beforeEach(() => {
    authServiceSpy = jasmine.createSpyObj('AuthService', ['refreshToken', 'logout']);
    TestBed.configureTestingModule({
      imports: [HttpClientTestingModule],
      providers: [
        JwtInterceptor,
        { provide: HTTP_INTERCEPTORS, useClass: JwtInterceptor, multi: true },
        { provide: AuthService, useValue: authServiceSpy }
      ]
    });
    httpMock = TestBed.inject(HttpTestingController);
    httpClient = TestBed.inject(HttpClient);
  });
  afterEach(() => {
    httpMock.verify();
  });
  it('should refresh token on 401 error and retry request', () => {
    authServiceSpy.refreshToken.and.returnValue(of(true));
    httpClient.get('/test').subscribe();
    const req = httpMock.expectOne('/test');
    req.flush(null, { status: 401, statusText: 'Unauthorized' });
    expect(authServiceSpy.refreshToken).toHaveBeenCalled();
  });
});

Extension des stratégies d'actualisation des jetons JWT avec des intercepteurs angulaires

Un aspect critique de l’utilisation d’un Angular Intercepteur de jetons JWT pour les applications sécurisées gère efficacement les complexités de la gestion de l'authentification et de l'expiration des sessions. Au-delà de la simple détection des erreurs 401 et de l'actualisation des jetons, il est essentiel de réfléchir à la gestion des requêtes multiples et à la manière d'optimiser l'actualisation des jetons. Lorsque plusieurs requêtes rencontrent simultanément une erreur 401, la mise en œuvre d’une file d’attente ou d’un mécanisme de verrouillage peut être extrêmement utile pour garantir qu’une seule actualisation de jeton se produit à la fois. Cette approche évite les appels d'API inutiles et réduit la charge, en particulier dans les applications à fort trafic, tout en permettant à toutes les requêtes en file d'attente de se poursuivre après l'actualisation.

Les intercepteurs d'Angular nous permettent également de rationaliser la façon dont nous gérons le stockage et la récupération des jetons. Plutôt que de coder en dur les jetons dans le stockage local, il est préférable d'utiliser celui d'Angular. Cookies HttpUniquement et protection CSRF pour améliorer la sécurité. Avec les cookies HttpOnly, le JWT ne peut pas être consulté ou manipulé par JavaScript, ce qui améliore considérablement la sécurité mais ajoute un nouveau défi : garantir que les requêtes récupèrent automatiquement le cookie actualisé. Intégré à Angular withCredentials L'option est une solution, demandant au navigateur d'inclure ces cookies à chaque requête.

Dans un environnement de production, il est conseillé d'exécuter des tests de performances sur le comportement de l'application sous charge avec des actualisations de jetons. Les configurations de test peuvent simuler des volumes de requêtes élevés, garantissant ainsi que la logique de l’intercepteur évolue efficacement. En pratique, cette configuration minimise le risque d'erreurs liées aux jetons impactant l'expérience utilisateur. La stratégie d’interception, lorsqu’elle est associée à une gestion et à des tests appropriés des cookies, permet de maintenir une application transparente, conviviale et sécurisée, que l’application gère des données financières critiques ou les sessions utilisateur d’une plateforme sociale. 🌐🔐