Løser JWT Refresh Token Handling i Angular med HttpInterceptor

Sikrer sømløs JWT-oppdatering i vinkelavskjærere

I en nettapp med sikre brukerøkter er effektiv administrasjon av kortvarige JWT-tokens avgjørende for en uavbrutt brukeropplevelse. Når tokens utløper, støter brukere ofte på problemer som å bli tvunget til å logge på på nytt, noe som kan være frustrerende og forstyrre brukerengasjementet. For å takle dette implementerer utviklere vanligvis automatisk tokenoppdatering ved å bruke en Angular interceptor for å håndtere utløpte økter. 🕰️

Denne tilnærmingen innebærer å avskjære HTTP-forespørsler, fange 401-feil (uautoriserte forespørsler), og deretter starte en oppdateringsprosess for å få et nytt token. Det kan imidlertid oppstå problemer med å sikre at det oppdaterte tokenet eller informasjonskapselen brukes på forespørslene på nytt. Hvis det nye tokenet ikke forplanter seg på riktig måte, kan forsøket på nytt mislykkes, slik at brukerne får samme autorisasjonsfeil og potensielt forstyrre appens arbeidsflyt.

I denne veiledningen går vi gjennom en praktisk implementering av dette skjæringsmønsteret. Vi skal se på hvordan du fanger opp feil, oppdaterer tokens og bekrefter at forespørsler prøver på nytt med gyldig autorisasjon. Denne tilnærmingen minimerer avbrudd samtidig som den gir deg kontroll over øktfornyelsesprosessen.

Mot slutten vil du få innsikt i hvordan du takler vanlige fallgruver, som å håndtere HttpOnly-informasjonskapsler og administrere oppdateringssekvenser under høye forespørselsvolumer. Denne metoden sikrer at applikasjonen din kan opprettholde en sikker, jevn brukerøkt uten konstant pålogging. 🔒

Sikre pålitelig JWT-autentisering med vinkelavskjærere

I eksemplet ovenfor er interceptoren designet for å automatisk oppdatere et kortvarig JWT-token hver gang en 401-feil oppstår. Denne typen oppsett er viktig i applikasjoner med sensitive data, der det er viktig å opprettholde øktsikkerhet, men brukeropplevelsen ikke bør avbrytes. Interceptoren fanger opp 401 (uautorisert) feilen og starter en forespørsel om oppdateringstoken for å fornye økten uten at brukeren må autentisere seg på nytt. Denne prosessen utløses av catchError-funksjonen, som tillater feilhåndtering i en observerbar pipeline. Her signaliserer enhver HTTP-feil, spesifikt en 401, at tokenet sannsynligvis har utløpt og starter oppdateringsprosessen.

Funksjonen switchMap er et annet kjerneelement her; den oppretter en ny observerbar strøm for den oppdaterte forespørselen, og erstatter den gamle observerbare uten å kansellere hele flyten. Etter oppdatering prøver den den opprinnelige forespørselen på nytt, og sikrer at det nye tokenet brukes. Ved å bytte fra den gamle observerbare til en ny, kan interceptoren utføre token-fornyelsen på en sømløs, ikke-blokkerende måte. Denne teknikken er spesielt verdifull når du arbeider med sanntidsapplikasjoner, siden den reduserer avbrudd i brukerinteraksjoner samtidig som sikker autentisering opprettholdes. For eksempel vil en bruker som surfer på et sikret finansielt dashbord ikke bli omdirigert eller logget ut unødvendig; i stedet hentes det nye tokenet og brukes i bakgrunnen. 🔄

I tillegg spiller BehaviorSubject en avgjørende rolle ved å administrere tilstanden til oppdateringsprosessen. Dette RxJS-verktøyet kan beholde den siste utsendte verdien, noe som er spesielt nyttig når flere forespørsler støter på en 401-feil samtidig. I stedet for å utløse flere oppdateringer, starter interceptoren bare én token-oppdatering, og alle andre forespørsler står i kø for å vente på denne enkelt-token-fornyelsen. Bruk av BehaviorSubject med switchMap bidrar til å sikre at hvis en forespørsel utløser oppdateringen, vil alle andre forespørsler som trenger det nye tokenet bruke den oppdaterte legitimasjonen uten å forårsake gjentatte oppdateringsoppkall. Denne funksjonen er ekstremt nyttig i tilfeller der brukere kan ha flere åpne faner, eller appen administrerer flere samtidige nettverksanrop, og dermed sparer ressurser og unngår overdreven serverbelastning.

Å teste denne avskjæringslogikken er også viktig for å sikre at den fungerer under forskjellige scenarier, og det er derfor vi inkluderer HttpTestingController. Dette vinkeltestverktøyet gjør det mulig for oss å simulere og teste HTTP-svar, som 401 Uautorisert status, i et kontrollert miljø. Ved å bruke flush, en metode levert av HttpTestingController, kan utviklere simulere virkelige feilresponser og verifisere at interceptoren oppfører seg som forventet. Denne testtilnærmingen lar oss avgrense hvor godt oppdateringslogikken håndterer ulike tilfeller før vi distribuerer appen. Med disse metodene bevarer interceptoren ikke bare økten sikkert, men gir også en mer sømløs, stabil opplevelse for brukere som navigerer i appen. 👩‍💻

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

Utvider JWT Token Refresh Strategies med Angular Interceptors

Et kritisk aspekt ved bruk av en Angular JWT token interceptor for sikre applikasjoner håndterer effektivt kompleksiteten ved å administrere autentisering og utløp av økter. I tillegg til å bare fange 401-feil og oppdatere tokens, er det viktig å tenke på håndtering av flere forespørsler og hvordan du kan optimalisere tokenoppdateringer. Når flere forespørsler støter på en 401-feil samtidig, kan implementering av en kø eller låsemekanisme være ekstremt nyttig for å sikre at bare én token-oppdatering skjer om gangen. Denne tilnærmingen forhindrer unødvendige API-kall og reduserer belastningen, spesielt i høytrafikkapplikasjoner, samtidig som alle forespørsler i kø kan fortsette etter oppdateringen.

Angular interceptor lar oss også effektivisere hvordan vi håndterer token-lagring og -henting. I stedet for å hardkode tokens i lokal lagring, er det best å bruke Angular HttpOnly cookies og CSRF-beskyttelse for å øke sikkerheten. Med HttpOnly-informasjonskapsler kan ikke JWT få tilgang til eller manipuleres av JavaScript, noe som forbedrer sikkerheten betraktelig, men legger til en ny utfordring: å sikre at forespørsler henter den oppdaterte informasjonskapselen automatisk. Angular er innebygd withCredentials alternativet er en løsning, og instruerer nettleseren til å inkludere disse informasjonskapslene på hver forespørsel.

I et produksjonsmiljø er det tilrådelig å kjøre ytelsestester på hvordan applikasjonen oppfører seg under belastning med tokenoppdateringer. Testoppsett kan simulere høye forespørselsvolumer, noe som sikrer at avskjærerens logikk skaleres effektivt. I praksis minimerer dette oppsettet risikoen for token-relaterte feil som påvirker brukeropplevelsen. Avskjæringsstrategien, når den er sammenkoblet med riktig håndtering og testing av informasjonskapsler, bidrar til å opprettholde en sømløs, brukervennlig og sikker applikasjon – enten appen administrerer kritiske økonomiske data eller en sosial plattforms brukerøkter. 🌐🔐