Where should expired token handling live in Angular—interceptor or guard—to avoid infinite retry loops while enforcing least-privilege navigation?

Question

ContextAngular provides no built-in authentication, session management, or token-refresh service. Developers must implement expired credential handling using HttpClient interceptors for API calls and router guards for navigation protection.ProblemWhen an access token expires, a 401 response triggers the interceptor to refresh and retry. However, if the refresh itself fails with 401, the interceptor can loop indefinitely without a guard flag or custom header marking already-retried requests. Interceptors cannot block navigation, while guards can prevent route access but cannot intercept API 401 responses.ConstraintsFunctional interceptors (HttpInterceptorFn) available since Angular 15; class-based interceptors still commonConcurrent requests as token expires can each trigger refresh; standard pattern shares single refresh ObservableRouter guards (CanActivate, CanActivateChild, CanMatch) only run at navigation timeClient-side JWT validation is UX-only; server must re-authorize every requestToken storage choice (browser storage vs HttpOnly cookie) affects XSS/CSRF trade-offsUnresolved DecisionThe Angular guides do not prescribe where expiry handling belongs—a guard sees navigation but not API 401s, while an interceptor sees 401s but cannot block navigation. Teams must choose a single owner, usually the interceptor, but this creates tension with least-privilege route protection.QuestionsCan a single architectural pattern exist where both interceptors and guards coordinate without infinite retry loops?What is the recommended approach to mark a request as already-retried to prevent refresh loops?How should teams implement role-based route protection while ensuring API calls are always re-authorized server-side?

Tasadduq Burney · Answer

AnswerPlace token‑refresh logic in an HttpClient interceptor and keep navigation/role checks in router guards. The interceptor retries a request only once after a failed refresh, while the guard decides whether a route can be accessed based on the current auth state.Confirmed factsAngular 15+ provides functional interceptors (HttpInterceptorFn) that can catch 401 responses.Router guards (CanActivate, CanMatch) run only on navigation and cannot make HTTP calls.A shared refresh observable prevents parallel refresh requests when multiple calls expire at the same time.Steps for this caseCreate an auth service that exposes:loggedIn: booleanrefreshing$: Observable (shared via shareReplay)methods to login, logout, and retrieve user roles/claims.Implement the interceptor (functional or class‑based):On each request, clone it and add an Authorization header if a valid token exists.If the response is 401:Check for a custom header (e.g., X-Refresh-Attempted) to see if a refresh was already tried.If not tried, set the header on a cloned request, call authService.refreshToken() (which returns the shared refresh observable), and switchMap to retry the original request.If already tried, let the error propagate (no infinite loop).Implement the guard (CanActivate/CanMatch):Read authService.loggedIn and authService.userRoles.If not logged in, redirect to login page.If logged in but lacking required role, redirect to an unauthorized page.Do not call refreshToken() here; rely on the interceptor for API 401 handling.Wire everything: provide the auth service in root, register the interceptor via HTTP_INTERCEPTORS, and add the guard to protected routes.

Where should expired token handling live in Angular—interceptor or guard—to avoid infinite retry loops while enforcing least-privilege navigation?

Context

Problem

Constraints

Unresolved Decision

Questions

1 answer

Answer

Confirmed facts

Steps for this case

Your perspective belongs here.

0 question comments