Het oplossen van JWT Refresh Token-verwerking in Angular met HttpInterceptor

Zorgen voor naadloze JWT-vernieuwing in hoekige interceptors

In een webapp met beveiligde gebruikerssessies is het effectief beheren van kortstondige JWT-tokens cruciaal voor een ononderbroken gebruikerservaring. Wanneer tokens verlopen, ondervinden gebruikers vaak problemen, zoals het gedwongen opnieuw inloggen, wat frustrerend kan zijn en de betrokkenheid van gebruikers kan verstoren. Om dit aan te pakken, implementeren ontwikkelaars gewoonlijk automatische tokenvernieuwing met behulp van een Angular-interceptor om verlopen sessies af te handelen. 🕰️

Deze aanpak omvat het onderscheppen van HTTP-verzoeken, het onderscheppen van 401-fouten (niet-geautoriseerde verzoeken) en het vervolgens starten van een vernieuwingsproces om een ​​nieuw token te verkrijgen. Er kunnen echter problemen optreden bij het garanderen dat het bijgewerkte token of cookie wordt toegepast op de opnieuw geprobeerde verzoeken. Als het nieuwe token niet correct wordt doorgegeven, kan de nieuwe poging mislukken, waardoor gebruikers met dezelfde autorisatiefout blijven zitten en de app-workflows mogelijk worden verstoord.

In deze handleiding bespreken we een praktische implementatie van dit interceptorpatroon. We bekijken hoe u fouten kunt opsporen, tokens kunt vernieuwen en kunt bevestigen dat verzoeken opnieuw worden geprobeerd met geldige autorisatie. Deze aanpak minimaliseert onderbrekingen en geeft u controle over het sessievernieuwingsproces.

Aan het einde krijgt u inzicht in hoe u veelvoorkomende valkuilen kunt aanpakken, zoals het omgaan met HttpOnly-cookies en het beheren van vernieuwingsreeksen tijdens hoge verzoekvolumes. Deze methode zorgt ervoor dat uw applicatie een veilige, soepele gebruikerssessie kan onderhouden zonder voortdurend inloggen. 🔒

Garanderen van betrouwbare JWT-authenticatie met Angular Interceptors

In het bovenstaande voorbeeld is de interceptor ontworpen om automatisch een kortstondig JWT-token te vernieuwen wanneer er een 401-fout wordt aangetroffen. Dit soort instellingen is essentieel in toepassingen met gevoelige gegevens, waarbij het handhaven van sessiebeveiliging van cruciaal belang is, maar de gebruikerservaring niet mag worden onderbroken. De interceptor vangt de 401 (niet-geautoriseerde) fout op en initieert een vernieuwingstokenverzoek om de sessie te vernieuwen zonder dat de gebruiker zich opnieuw hoeft te authenticeren. Dit proces wordt geactiveerd door de functie catchError, die foutafhandeling binnen een waarneembare pijplijn mogelijk maakt. Hier geeft elke HTTP-fout, met name een 401, aan dat het token waarschijnlijk is verlopen en wordt het vernieuwingsproces gestart.

De functie switchMap is hier een ander kernelement; het creëert een nieuwe waarneembare stroom voor het vernieuwde verzoek, waarbij de oude waarneembare stroom wordt vervangen zonder de hele stroom te annuleren. Na het vernieuwen wordt het oorspronkelijke verzoek opnieuw uitgevoerd, waarbij ervoor wordt gezorgd dat het nieuwe token wordt toegepast. Door over te schakelen van het oude waarneembare naar het nieuwe, kan de interceptor de tokenvernieuwing op een naadloze, niet-blokkerende manier uitvoeren. Deze techniek is vooral waardevol bij het werken met realtime applicaties, omdat het onderbrekingen in gebruikersinteracties vermindert terwijl de veilige authenticatie behouden blijft. Een gebruiker die door een beveiligd financieel dashboard bladert, wordt bijvoorbeeld niet onnodig omgeleid of uitgelogd; in plaats daarvan wordt het nieuwe token op de achtergrond verkregen en toegepast. 🔄

Bovendien speelt het BehaviorSubject een cruciale rol bij het beheren van de status van het vernieuwingsproces. Dit RxJS-hulpprogramma kan de laatst verzonden waarde behouden, wat vooral handig is wanneer meerdere verzoeken tegelijkertijd een 401-fout tegenkomen. In plaats van meerdere vernieuwingen te activeren, initieert de interceptor slechts één tokenvernieuwing en worden alle andere verzoeken in de wachtrij geplaatst om te wachten op deze enkele tokenvernieuwing. Het gebruik van BehaviorSubject met switchMap zorgt ervoor dat als één verzoek de vernieuwing activeert, alle andere verzoeken waarvoor het nieuwe token nodig is, de bijgewerkte inloggegevens zullen gebruiken zonder herhaalde vernieuwingsaanroepen te veroorzaken. Deze functie is uiterst nuttig in gevallen waarin gebruikers meerdere geopende tabbladen hebben, of de app meerdere gelijktijdige netwerkoproepen beheert, waardoor bronnen worden bespaard en overmatige serverbelasting wordt vermeden.

Het testen van deze interceptorlogica is ook essentieel om ervoor te zorgen dat deze onder verschillende scenario's werkt. Daarom nemen we de HttpTestingController op. Met deze Angular-testtool kunnen we HTTP-reacties, zoals de 401 Unauthorized-status, in een gecontroleerde omgeving simuleren en testen. Met behulp van flush, een methode van HttpTestingController, kunnen ontwikkelaars foutreacties uit de echte wereld simuleren en verifiëren dat de interceptor zich gedraagt ​​zoals verwacht. Met deze testaanpak kunnen we verfijnen hoe goed de vernieuwingslogica verschillende cases afhandelt voordat de app wordt geïmplementeerd. Met deze methoden bewaart de interceptor niet alleen de sessie veilig, maar biedt hij ook een meer naadloze, stabiele ervaring voor gebruikers die door de app navigeren. 👩‍💻

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

Uitbreiding van JWT-tokenvernieuwingsstrategieën met hoekige interceptors

Een cruciaal aspect van het gebruik van een Angular JWT-token-interceptor voor veilige toepassingen gaat efficiënt om met de complexiteit van het beheer van authenticatie en het verlopen van sessies. Naast het alleen opvangen van 401-fouten en het vernieuwen van tokens, is het essentieel om na te denken over de afhandeling van meerdere verzoeken en hoe u het vernieuwen van tokens kunt optimaliseren. Wanneer meerdere verzoeken tegelijkertijd een 401-fout tegenkomen, kan het implementeren van een wachtrij- of vergrendelingsmechanisme uiterst nuttig zijn om ervoor te zorgen dat er slechts één tokenvernieuwing tegelijk plaatsvindt. Deze aanpak voorkomt onnodige API-aanroepen en vermindert de belasting, vooral bij toepassingen met veel verkeer, terwijl alle verzoeken in de wachtrij na de vernieuwing door kunnen gaan.

Met de interceptors van Angular kunnen we ook de manier waarop we omgaan met de opslag en het ophalen van tokens stroomlijnen. In plaats van tokens hard te coderen in de lokale opslag, kunt u het beste Angular's gebruiken HttpOnly-cookies en CSRF-bescherming om de veiligheid te verbeteren. Met HttpOnly-cookies kan de JWT niet worden benaderd of gemanipuleerd door JavaScript, waardoor de beveiliging aanzienlijk wordt verbeterd, maar een nieuwe uitdaging wordt toegevoegd: ervoor zorgen dat verzoeken de vernieuwde cookie automatisch oppikken. Angular is ingebouwd withCredentials optie is een oplossing, waarbij de browser wordt geïnstrueerd om deze cookies bij elk verzoek op te nemen.

In een productieomgeving is het raadzaam om prestatietests uit te voeren over hoe de applicatie zich gedraagt ​​onder belasting met tokenvernieuwingen. Testopstellingen kunnen hoge verzoekvolumes simuleren, waardoor de logica van de interceptor efficiënt kan worden geschaald. In de praktijk minimaliseert deze opstelling het risico op tokengerelateerde fouten die van invloed zijn op de gebruikerservaring. De interceptorstrategie, gecombineerd met de juiste omgang met en testen van cookies, helpt een naadloze, gebruiksvriendelijke en veilige applicatie te behouden, ongeacht of de app kritieke financiële gegevens beheert of de gebruikerssessies van een sociaal platform. 🌐🔐