Auflösen der JWT-Refresh-Token-Verarbeitung in Angular mit HttpInterceptor

Gewährleistung einer nahtlosen JWT-Aktualisierung in Angular Interceptors

In einer Web-App mit sicheren Benutzersitzungen ist die effektive Verwaltung von kurzlebigen JWT-Tokens für ein unterbrechungsfreies Benutzererlebnis von entscheidender Bedeutung. Wenn Token ablaufen, stoßen Benutzer oft auf Probleme, wie zum Beispiel, dass sie sich erneut anmelden müssen, was frustrierend sein und die Benutzerinteraktion stören kann. Um dieses Problem zu lösen, implementieren Entwickler üblicherweise eine automatische Token-Aktualisierung mithilfe eines Angular-Interceptors, um abgelaufene Sitzungen zu verarbeiten. 🕰️

Bei diesem Ansatz werden HTTP-Anfragen abgefangen, 401-Fehler (nicht autorisierte Anfragen) abgefangen und anschließend ein Aktualisierungsprozess aufgerufen, um ein neues Token zu erhalten. Allerdings kann es zu Problemen kommen, wenn sichergestellt wird, dass das aktualisierte Token oder Cookie auf die wiederholten Anfragen angewendet wird. Wenn das neue Token nicht ordnungsgemäß weitergegeben wird, schlägt der erneute Versuch möglicherweise fehl, sodass Benutzer denselben Autorisierungsfehler haben und möglicherweise die App-Workflows unterbrochen werden.

In diesem Leitfaden gehen wir durch eine praktische Implementierung dieses Interceptor-Musters. Wir schauen uns an, wie man Fehler abfängt, Token aktualisiert und bestätigt, dass Anfragen mit gültiger Autorisierung wiederholt werden. Dieser Ansatz minimiert Unterbrechungen und gibt Ihnen gleichzeitig die Kontrolle über den Sitzungserneuerungsprozess.

Am Ende erhalten Sie Einblicke in die Behebung häufiger Fallstricke, wie den Umgang mit HttpOnly-Cookies und die Verwaltung von Aktualisierungssequenzen bei hohem Anfragevolumen. Diese Methode stellt sicher, dass Ihre Anwendung eine sichere, reibungslose Benutzersitzung ohne ständige Anmeldungen aufrechterhalten kann. 🔒

Gewährleistung einer zuverlässigen JWT-Authentifizierung mit Angular Interceptors

Im obigen Beispiel ist der Interceptor so konzipiert, dass er automatisch ein kurzlebiges JWT-Token aktualisiert, wenn ein 401-Fehler auftritt. Diese Art der Einrichtung ist bei Anwendungen mit sensiblen Daten unerlässlich, bei denen die Aufrechterhaltung der Sitzungssicherheit von entscheidender Bedeutung ist, das Benutzererlebnis jedoch nicht beeinträchtigt werden sollte. Der Interceptor fängt den Fehler 401 (Unauthorized) ab und initiiert eine Aktualisierungstokenanforderung, um die Sitzung zu erneuern, ohne dass sich der Benutzer erneut authentifizieren muss. Dieser Prozess wird durch die Funktion „catchError“ ausgelöst, die eine Fehlerbehandlung innerhalb einer beobachtbaren Pipeline ermöglicht. Hier signalisiert jeder HTTP-Fehler, insbesondere ein 401, dass das Token wahrscheinlich abgelaufen ist, und leitet den Aktualisierungsprozess ein.

Die Funktion switchMap ist hier ein weiteres Kernelement; Es erstellt einen neuen Observable-Stream für die aktualisierte Anfrage und ersetzt den alten Observable-Stream, ohne den gesamten Fluss abzubrechen. Nach der Aktualisierung wiederholt es die ursprüngliche Anfrage und stellt so sicher, dass das neue Token angewendet wird. Durch den Wechsel vom alten Observablen zum neuen kann der Interceptor die Token-Erneuerung nahtlos und nicht blockierend durchführen. Diese Technik ist besonders wertvoll bei der Arbeit mit Echtzeitanwendungen, da sie Unterbrechungen bei Benutzerinteraktionen reduziert und gleichzeitig eine sichere Authentifizierung gewährleistet. Beispielsweise würde ein Benutzer, der ein gesichertes Finanz-Dashboard durchsucht, nicht unnötigerweise umgeleitet oder abgemeldet; Stattdessen wird der neue Token im Hintergrund erworben und angewendet. 🔄

Darüber hinaus spielt das BehaviorSubject eine entscheidende Rolle bei der Verwaltung des Status des Aktualisierungsprozesses. Dieses RxJS-Dienstprogramm kann den zuletzt ausgegebenen Wert beibehalten, was besonders hilfreich ist, wenn bei mehreren Anfragen gleichzeitig ein 401-Fehler auftritt. Anstatt mehrere Aktualisierungen auszulösen, initiiert der Interceptor nur eine Token-Aktualisierung und alle anderen Anforderungen werden in die Warteschlange gestellt, um auf diese einzelne Token-Erneuerung zu warten. Durch die Verwendung von BehaviorSubject mit switchMap wird sichergestellt, dass, wenn eine Anfrage die Aktualisierung auslöst, alle anderen Anfragen, die das neue Token benötigen, die aktualisierten Anmeldeinformationen verwenden, ohne dass es zu wiederholten Aktualisierungsaufrufen kommt. Diese Funktion ist äußerst hilfreich, wenn Benutzer mehrere Tabs geöffnet haben oder die App mehrere gleichzeitige Netzwerkanrufe verwaltet, wodurch Ressourcen gespart und eine übermäßige Serverlast vermieden wird.

Das Testen dieser Interceptor-Logik ist auch wichtig, um sicherzustellen, dass sie in verschiedenen Szenarien funktioniert, weshalb wir den HttpTestingController einschließen. Mit diesem Angular-Testtool können wir HTTP-Antworten wie den Status „401 Nicht autorisiert“ in einer kontrollierten Umgebung simulieren und testen. Mithilfe von Flush, einer von HttpTestingController bereitgestellten Methode, können Entwickler reale Fehlerreaktionen simulieren und überprüfen, ob sich der Interceptor wie erwartet verhält. Mit diesem Testansatz können wir vor der Bereitstellung der App verfeinern, wie gut die Aktualisierungslogik verschiedene Fälle verarbeitet. Mit diesen Methoden bewahrt der Interceptor nicht nur die Sitzung sicher auf, sondern bietet Benutzern, die in der App navigieren, auch ein nahtloseres und stabileres Erlebnis. 👩‍💻

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

Erweiterung der JWT-Token-Aktualisierungsstrategien mit Angular Interceptors

Ein kritischer Aspekt bei der Verwendung eines Angular JWT-Token-Interceptor Für sichere Anwendungen geht es darum, die Komplexität der Authentifizierungsverwaltung und des Sitzungsablaufs effizient zu bewältigen. Über das bloße Abfangen von 401-Fehlern und das Aktualisieren von Token hinaus ist es wichtig, über die Handhabung mehrerer Anfragen und die Optimierung von Token-Aktualisierungen nachzudenken. Wenn bei mehreren Anfragen gleichzeitig ein 401-Fehler auftritt, kann die Implementierung einer Warteschlange oder eines Sperrmechanismus äußerst nützlich sein, um sicherzustellen, dass jeweils nur eine Token-Aktualisierung erfolgt. Dieser Ansatz verhindert unnötige API-Aufrufe und reduziert die Last, insbesondere bei Anwendungen mit hohem Datenverkehr, während alle in der Warteschlange befindlichen Anforderungen nach der Aktualisierung fortgesetzt werden können.

Mit den Interceptoren von Angular können wir auch die Art und Weise optimieren, wie wir die Speicherung und den Abruf von Token handhaben. Anstatt Token im lokalen Speicher fest zu codieren, verwenden Sie am besten die von Angular HttpOnly-Cookies und CSRF-Schutz zur Erhöhung der Sicherheit. Mit HttpOnly-Cookies kann JavaScript nicht auf das JWT zugreifen oder es manipulieren, was die Sicherheit erheblich verbessert, aber auch eine neue Herausforderung mit sich bringt: Sicherstellen, dass Anfragen das aktualisierte Cookie automatisch abrufen. Angular ist integriert withCredentials Eine Lösung ist die Option, die den Browser anweist, diese Cookies bei jeder Anfrage einzubinden.

In einer Produktionsumgebung ist es ratsam, Leistungstests durchzuführen, um zu prüfen, wie sich die Anwendung unter Last mit Token-Aktualisierungen verhält. Testaufbauten können ein hohes Anforderungsvolumen simulieren und so sicherstellen, dass die Logik des Abfangjägers effizient skaliert. In der Praxis minimiert dieses Setup das Risiko tokenbezogener Fehler, die sich auf die Benutzererfahrung auswirken. Die Interceptor-Strategie trägt in Kombination mit der richtigen Handhabung und Prüfung von Cookies dazu bei, eine nahtlose, benutzerfreundliche und sichere Anwendung aufrechtzuerhalten – unabhängig davon, ob die App wichtige Finanzdaten oder die Benutzersitzungen einer sozialen Plattform verwaltet. 🌐🔐