In an Angular app, how should an auth interceptor refresh an expired access token on a 401 and replay the request without five concurrent failures triggering five refreshes?

## The flow in one picture 1. A request goes out with an access token that has just expired. 2. The API answers **401 Unauthorized**; `HttpClient` delivers an `HttpErrorResponse` with `status` 401 on the error channel. 3. The interceptor catches it, obtains a new access token (usually by calling a refresh endpoint that uses a long-lived, httpOnly refresh cookie), and **replays** the original request with the new token. 4. The caller receives the replayed response and never knows a refresh happened. Each step has a trap. ## Catch only what you mean to handle ```ts return next(withToken(req, auth.accessToken())).pipe( catchError((err: unknown) => { if (!(err instanceof HttpErrorResponse) || err.status !== HttpStatusCode.Unauthorized) { return throwError(() => err); } return auth.refreshToken().pipe(switchMap((token) => next(withToken(req, token)))); }), ); ``` - Narrow with `instanceof HttpErrorResponse` and check `status === 401`; network failures (status 0), 403 and 5xx are not token problems. - Replay with **`next(...)`**, not `http.get(...)`. Calling `next()` again runs the interceptors after this one and the backend with the new request; the replay does not re-enter this interceptor, so a second 401 simply propagates instead of looping. - `inject(AuthService)` happens synchronously at the top of the interceptor. The `catchError` callback runs later, outside the injection context, where `inject()` would fail with NG0203. ## One refresh for many failures A dashboard that fires five requests at once gets five 401s at nearly the same moment. A naive interceptor starts five refreshes; with rotating refresh tokens, the second one may present a token the first already used, the server rejects it, and the user is logged out. The fix is a **single in-flight refresh** held by the auth service: - The first 401 creates the refresh Observable and stores it. - Later 401s find it stored and subscribe to the same one. - `shareReplay(1)` makes all subscribers share one HTTP call and receive the same new token. - When the refresh finishes (success or error), the stored reference is cleared so the next expiry starts a fresh refresh. ## The refresh call must bypass the interceptor The refresh request goes through the same `HttpClient`, so it passes through the auth interceptor too. If it carried the expired token and received its own 401, the interceptor would ask for a refresh — and get the *same* in-flight Observable, which is waiting for this very request. Nothing would ever complete. Mark the refresh call with a context token such as `SKIP_AUTH` and have the interceptor forward such requests untouched. ## When the refresh fails - A 401 or 400 from the refresh endpoint means the session is over: clear tokens, route to the login page, and rethrow so callers stop waiting. - Do this once, in the auth service's refresh pipeline, rather than in every waiting request's error handler. - A network failure during refresh is not a logout reason; rethrow it as an ordinary error. ## Design choices a senior answer mentions | Choice | Option A | Option B | |---|---|---| | When to refresh | Reactively, on 401 | Proactively, before the known expiry time | | Token storage | In memory, refresh cookie httpOnly | Web storage, readable by any script on the page | | Waiting requests during refresh | Queue on the shared Observable | Fail fast and let callers retry | | Non-idempotent requests | Replay: the 401 means the server rejected the request before acting on it | Do not replay if your API can partially apply work before authorising | A proactive refresh reduces the number of 401s but does not remove the need for the reactive path, because clocks drift and tokens can be revoked server-side. ## Testing it The behaviour worth pinning in tests: five concurrent 401s produce exactly one refresh request, every original request is replayed once with the new token, a rejected refresh logs out once, and the refresh request never carries the bearer header.