Risoluzione della gestione del token di aggiornamento JWT in Angular con HttpInterceptor

Garantire l'aggiornamento JWT senza soluzione di continuità negli Interceptor angolari

In un'app Web con sessioni utente sicure, la gestione efficace dei token JWT di breve durata è fondamentale per un'esperienza utente ininterrotta. Quando i token scadono, gli utenti spesso riscontrano problemi come essere costretti a effettuare nuovamente l'accesso, il che può essere frustrante e interrompere il coinvolgimento degli utenti. Per affrontare questo problema, gli sviluppatori implementano comunemente l'aggiornamento automatico dei token utilizzando un interceptor Angular per gestire le sessioni scadute. 🕰️

Questo approccio prevede l'intercettazione delle richieste HTTP, il rilevamento degli errori 401 (richieste non autorizzate) e quindi l'invocazione di un processo di aggiornamento per ottenere un nuovo token. Tuttavia, possono sorgere problemi nel garantire che il token o il cookie aggiornato venga applicato alle richieste ripetute. Se il nuovo token non si propaga correttamente, il nuovo tentativo potrebbe non riuscire, lasciando agli utenti lo stesso errore di autorizzazione e potenzialmente interrompendo i flussi di lavoro dell'app.

In questa guida esamineremo un'implementazione pratica di questo pattern interceptor. Vedremo come rilevare errori, aggiornare i token e confermare che le richieste riprovano con un'autorizzazione valida. Questo approccio riduce al minimo le interruzioni offrendoti al contempo il controllo sul processo di rinnovo della sessione.

Alla fine, acquisirai informazioni su come affrontare le insidie ​​​​comuni, come la gestione dei cookie HttpOnly e la gestione delle sequenze di aggiornamento durante volumi di richieste elevati. Questo metodo garantisce che la tua applicazione possa mantenere una sessione utente sicura e fluida senza accessi costanti. 🔒

Garantire un'autenticazione JWT affidabile con Angular Interceptor

Nell'esempio precedente, l'interceptor è progettato per aggiornare automaticamente un token JWT di breve durata ogni volta che viene rilevato un errore 401. Questo tipo di configurazione è essenziale nelle applicazioni con dati sensibili, dove il mantenimento della sicurezza della sessione è fondamentale, ma l'esperienza dell'utente non deve essere interrotta. L'interceptor rileva l'errore 401 (Non autorizzato) e avvia una richiesta di token di aggiornamento per rinnovare la sessione senza richiedere all'utente di autenticarsi nuovamente. Questo processo viene attivato dalla funzione catchError, che consente la gestione degli errori all'interno di una pipeline osservabile. In questo caso, qualsiasi errore HTTP, in particolare un 401, segnala che probabilmente il token è scaduto e avvia il processo di aggiornamento.

La funzione switchMap è un altro elemento fondamentale qui; crea un nuovo flusso osservabile per la richiesta aggiornata, sostituendo il vecchio osservabile senza annullare l'intero flusso. Dopo l'aggiornamento, ritenta la richiesta originale, assicurandosi che il nuovo token venga applicato. Passando dal vecchio osservabile a uno nuovo, l'interceptor può eseguire il rinnovo del token in modo continuo e senza blocchi. Questa tecnica è particolarmente utile quando si lavora con applicazioni in tempo reale, poiché riduce le interruzioni nelle interazioni dell'utente pur mantenendo l'autenticazione sicura. Ad esempio, un utente che naviga in un dashboard finanziario protetto non verrebbe reindirizzato o disconnesso inutilmente; invece, il nuovo token viene acquisito e applicato in background. 🔄

Inoltre, BehaviorSubject svolge un ruolo cruciale gestendo lo stato del processo di aggiornamento. Questa utility RxJS può conservare l'ultimo valore emesso, il che è particolarmente utile quando più richieste riscontrano un errore 401 contemporaneamente. Invece di attivare più aggiornamenti, l'interceptor avvia solo un aggiornamento del token e tutte le altre richieste vengono accodate in attesa del rinnovo di questo singolo token. L'utilizzo di BehaviorSubject con switchMap aiuta a garantire che se una richiesta attiva l'aggiornamento, tutte le altre richieste che necessitano del nuovo token utilizzeranno le credenziali aggiornate senza causare ripetute chiamate di aggiornamento. Questa funzionalità è estremamente utile nei casi in cui gli utenti possono avere più schede aperte o l'app gestisce più chiamate di rete simultanee, risparmiando così risorse ed evitando un carico eccessivo del server.

Testare questa logica dell'interceptor è essenziale anche per garantire che funzioni in scenari diversi, motivo per cui includiamo HttpTestingController. Questo strumento di test Angular ci consente di simulare e testare le risposte HTTP, come lo stato 401 Unauthorized, in un ambiente controllato. Utilizzando flush, un metodo fornito da HttpTestingController, gli sviluppatori possono simulare le risposte agli errori del mondo reale e verificare che l'interceptor si comporti come previsto. Questo approccio di test ci consente di perfezionare il modo in cui la logica di aggiornamento gestisce vari casi prima di distribuire l'app. Con questi metodi, l'interceptor non solo preserva la sessione in modo sicuro, ma fornisce anche un'esperienza più fluida e stabile per gli utenti che navigano nell'app. 👩‍💻

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();
  });
});

Espansione delle strategie di aggiornamento dei token JWT con Interceptor angolari

Un aspetto critico dell'utilizzo di Angular Intercettatore di token JWT per applicazioni sicure gestisce in modo efficiente le complessità legate alla gestione dell'autenticazione e della scadenza delle sessioni. Oltre al semplice rilevamento degli errori 401 e all'aggiornamento dei token, è essenziale pensare alla gestione di richieste multiple e a come ottimizzare gli aggiornamenti dei token. Quando più richieste riscontrano un errore 401 contemporaneamente, l'implementazione di una coda o di un meccanismo di blocco può essere estremamente utile per garantire che venga eseguito un solo aggiornamento del token alla volta. Questo approccio impedisce chiamate API non necessarie e riduce il carico, soprattutto nelle applicazioni a traffico elevato, consentendo al tempo stesso a tutte le richieste in coda di procedere dopo l'aggiornamento.

Gli intercettori di Angular ci consentono inoltre di semplificare il modo in cui gestiamo l'archiviazione e il recupero dei token. Invece di codificare i token nello spazio di archiviazione locale, è meglio utilizzare quelli di Angular Cookie HttpOnly e protezione CSRF per migliorare la sicurezza. Con i cookie HttpOnly, non è possibile accedere o manipolare JWT tramite JavaScript, migliorando notevolmente la sicurezza ma aggiungendo una nuova sfida: garantire che le richieste raccolgano automaticamente il cookie aggiornato. Angular è integrato withCredentials L'opzione è una soluzione, indicando al browser di includere questi cookie in ogni richiesta.

In un ambiente di produzione, è consigliabile eseguire test delle prestazioni su come si comporta l'applicazione sotto carico con aggiornamenti dei token. Le configurazioni di test possono simulare elevati volumi di richieste, garantendo che la logica dell’interceptor si ridimensioni in modo efficiente. In pratica, questa configurazione riduce al minimo il rischio di errori relativi ai token che influiscono sull'esperienza dell'utente. La strategia di intercettazione, se abbinata alla corretta gestione e test dei cookie, aiuta a mantenere un'applicazione fluida, facile da usare e sicura, indipendentemente dal fatto che l'app gestisca dati finanziari critici o sessioni utente di una piattaforma social. 🌐🔐