Löser JWT Refresh Token Handling i Angular med HttpInterceptor

Säkerställer sömlös JWT-uppdatering i vinkelavskiljare

I en webbapp med säkra användarsessioner är det avgörande att effektivt hantera kortlivade JWT-tokens för en oavbruten användarupplevelse. När tokens löper ut stöter användare ofta på problem som att tvingas logga in igen, vilket kan vara frustrerande och störa användarens engagemang. För att hantera detta implementerar utvecklare vanligtvis automatisk tokenuppdatering med en Angular interceptor för att hantera utgångna sessioner. 🕰️

Det här tillvägagångssättet involverar avlyssning av HTTP-förfrågningar, fånga 401-fel (obehöriga förfrågningar) och sedan anropa en uppdateringsprocess för att få en ny token. Däremot kan problem uppstå när det gäller att säkerställa att den uppdaterade tokenen eller cookien tillämpas på de återförsökta begäranden. Om den nya tokenen inte sprider sig korrekt kan det hända att försöket igen misslyckas, vilket gör att användarna får samma auktoriseringsfel och potentiellt stör appens arbetsflöden.

I den här guiden går vi igenom en praktisk implementering av detta interceptormönster. Vi kommer att titta på hur man fångar upp fel, uppdaterar tokens och bekräftar att begäranden försöker igen med giltig auktorisering. Detta tillvägagångssätt minimerar avbrott samtidigt som du får kontroll över sessionsförnyelseprocessen.

I slutet kommer du att få insikter i hur du åtgärdar vanliga fallgropar, som att hantera HttpOnly-cookies och hantera uppdateringssekvenser under höga förfrågningsvolymer. Denna metod säkerställer att din applikation kan upprätthålla en säker, smidig användarsession utan ständiga inloggningar. 🔒

Säkerställer tillförlitlig JWT-autentisering med vinkelavskiljare

I exemplet ovan är interceptorn utformad för att automatiskt uppdatera en kortlivad JWT-token närhelst ett 401-fel påträffas. Den här typen av inställningar är avgörande i applikationer med känslig data, där det är viktigt att upprätthålla sessionssäkerhet, men användarupplevelsen inte bör avbrytas. Interceptorn fångar 401-felet (otillåtet) och initierar en begäran om uppdateringstoken för att förnya sessionen utan att användaren behöver autentisera sig på nytt. Denna process utlöses av catchError-funktionen, som tillåter felhantering inom en observerbar pipeline. Här signalerar varje HTTP-fel, särskilt en 401, att token sannolikt har gått ut och initierar uppdateringsprocessen.

Funktionen switchMap är ett annat kärnelement här; den skapar en ny observerbar ström för den uppdaterade begäran, och ersätter den gamla observerbara utan att avbryta hela flödet. Efter uppdatering försöker den den ursprungliga begäran igen och säkerställer att den nya tokenen tillämpas. Genom att byta från det gamla observerbara till ett nytt kan interceptorn utföra tokenförnyelsen på ett sömlöst, icke-blockerande sätt. Denna teknik är särskilt värdefull när du arbetar med realtidsapplikationer, eftersom den minskar avbrott i användarinteraktioner samtidigt som säker autentisering bibehålls. Till exempel skulle en användare som surfar på en säker finansiell instrumentpanel inte omdirigeras eller loggas ut i onödan; istället förvärvas den nya token och appliceras i bakgrunden. 🔄

Dessutom spelar BehaviorSubject en avgörande roll genom att hantera tillståndet för uppdateringsprocessen. Detta RxJS-verktyg kan behålla det senast emitterade värdet, vilket är särskilt användbart när flera förfrågningar stöter på ett 401-fel samtidigt. Istället för att utlösa flera uppdateringar, initierar interceptorn bara en token-uppdatering, och alla andra förfrågningar ställs i kö för att vänta på denna enda token-förnyelse. Att använda BehaviorSubject med switchMap hjälper till att säkerställa att om en begäran utlöser uppdateringen, kommer alla andra förfrågningar som behöver den nya token att använda de uppdaterade referenserna utan att orsaka upprepade uppdateringssamtal. Den här funktionen är extremt användbar i fall där användare kan ha flera öppna flikar, eller appen hanterar flera samtidiga nätverkssamtal, vilket sparar resurser och undviker överdriven serverbelastning.

Att testa denna interceptorlogik är också viktigt för att säkerställa att den fungerar under olika scenarier, och det är därför vi inkluderar HttpTestingController. Detta vinkeltestverktyg gör det möjligt för oss att simulera och testa HTTP-svar, som statusen 401 obehörig, i en kontrollerad miljö. Med hjälp av flush, en metod som tillhandahålls av HttpTestingController, kan utvecklare simulera verkliga felsvar och verifiera att interceptorn beter sig som förväntat. Denna testmetod låter oss förfina hur väl uppdateringslogiken hanterar olika fall innan appen distribueras. Med dessa metoder bevarar interceptorn inte bara sessionen säkert utan ger också en mer sömlös, stabil upplevelse för användare som navigerar 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();
  });
});

Utökar JWT Token Refresh Strategies med Angular Interceptors

En kritisk aspekt av att använda en Angular JWT token interceptor för säkra applikationer hanterar effektivt komplexiteten med att hantera autentisering och sessionsutgång. Förutom att bara fånga 401-fel och uppdatera tokens, är det viktigt att tänka på hantering av flera förfrågningar och hur man optimerar tokenuppdateringar. När flera förfrågningar stöter på ett 401-fel samtidigt, kan implementering av en kö eller låsmekanism vara extremt användbar för att säkerställa att endast en tokenuppdatering sker åt gången. Detta tillvägagångssätt förhindrar onödiga API-anrop och minskar belastningen, särskilt i applikationer med hög trafik, samtidigt som alla förfrågningar i kö kan fortsätta efter uppdateringen.

Angulars interceptorer tillåter oss också att effektivisera hur vi hanterar tokenlagring och hämtning. I stället för att hårdkoda tokens i lokal lagring är det bäst att använda Angulars HttpOnly cookies och CSRF-skydd för att förbättra säkerheten. Med HttpOnly-cookies kan JWT inte nås eller manipuleras av JavaScript, vilket avsevärt förbättrar säkerheten men lägger till en ny utmaning: att säkerställa att förfrågningar hämtar den uppdaterade cookien automatiskt. Angular är inbyggt withCredentials option är en lösning som instruerar webbläsaren att inkludera dessa cookies på varje begäran.

I en produktionsmiljö är det tillrådligt att köra prestandatester på hur applikationen beter sig under belastning med tokenuppdateringar. Testinställningar kan simulera höga förfrågningsvolymer, vilket säkerställer att interceptorns logik skalas effektivt. I praktiken minimerar denna inställning risken för tokenrelaterade fel som påverkar användarupplevelsen. Interceptorstrategin, när den paras ihop med korrekt cookiehantering och testning, hjälper till att upprätthålla en sömlös, användarvänlig och säker applikation – oavsett om appen hanterar kritisk ekonomisk data eller en social plattforms användarsessioner. 🌐🔐