Interceptors for authentication tokens in Angular - Deep Dive

Overview - Interceptors for authentication tokens

What is it?

Interceptors for authentication tokens are special pieces of code in Angular that automatically add security tokens to outgoing web requests. These tokens prove who you are to the server, so it knows you have permission to access certain data. Instead of adding tokens manually to every request, interceptors do this behind the scenes. This makes your app safer and easier to maintain.

Why it matters

Without interceptors, developers would have to add authentication tokens to every request by hand, which is slow and error-prone. Missing tokens can cause users to lose access or expose sensitive data. Interceptors ensure tokens are always included, keeping user sessions secure and improving user experience by avoiding repeated logins.

Where it fits

Before learning interceptors, you should understand Angular services and HTTP client basics. After mastering interceptors, you can explore advanced topics like token refresh strategies, error handling in HTTP requests, and securing routes with guards.

Mental Model

Core Idea

An interceptor is like a security guard that checks and attaches your ID badge (authentication token) to every outgoing request automatically.

Think of it like...

Imagine sending letters through a mailroom where a clerk attaches a stamp proving you paid postage. You don’t have to stamp each letter yourself; the clerk does it for you every time.

Outgoing HTTP Request
      ↓
┌─────────────────────┐
│   Interceptor Layer  │  <-- Adds authentication token
└─────────────────────┘
      ↓
┌─────────────────────┐
│   Server Receives    │
│   Request with Token │
└─────────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding HTTP Requests in Angular

Concept: Learn how Angular sends web requests using the HttpClient service.

Angular uses HttpClient to send requests to servers. You create a request by calling methods like get(), post(), or put() on HttpClient. These methods return an Observable that you can subscribe to for the response.

Result

You can fetch or send data to a server from your Angular app.

Knowing how Angular sends requests is essential before modifying or enhancing those requests with interceptors.

2

Foundation

What is an HTTP Interceptor?

Concept: Introduce the idea of interceptors as middleware that can inspect or change requests and responses.

An HTTP interceptor is a class that implements the HttpInterceptor interface. It has an intercept() method that runs on every HTTP request or response. You can use it to add headers, log data, or handle errors globally.

Result

You can modify or react to all HTTP traffic in one place.

Interceptors centralize request handling, reducing repetitive code and improving maintainability.

3

Intermediate

Adding Authentication Tokens Automatically

🤔Before reading on: do you think interceptors modify requests before or after they are sent? Commit to your answer.

Concept: Use interceptors to attach authentication tokens to every outgoing request automatically.

Inside the intercept() method, you clone the original request and add an Authorization header with the token. Then you pass the cloned request to next.handle() to continue the request chain.

Result

Every HTTP request includes the token without manual changes in each call.

Understanding that requests are immutable and must be cloned to add headers prevents common bugs.

4

Intermediate

Handling Missing or Expired Tokens Gracefully

🤔Before reading on: do you think interceptors should block requests if tokens are missing or expired? Commit to your answer.

Concept: Interceptors can check token validity and decide how to proceed if tokens are missing or expired.

You can check if the token exists and is valid before adding it. If missing or expired, you might redirect the user to login or refresh the token silently before retrying the request.

Result

Your app avoids sending invalid tokens and handles authentication smoothly.

Knowing how to handle token absence or expiration improves user experience and security.

5

Advanced

Chaining Multiple Interceptors for Complex Logic

🤔Before reading on: do you think multiple interceptors run in the order they are provided or randomly? Commit to your answer.

Concept: Angular allows multiple interceptors that run in a chain, each able to modify requests or responses.

You can provide several interceptors in your module. They run in the order registered for requests, and reverse order for responses. This lets you separate concerns like logging, error handling, and token management cleanly.

Result

Your app has modular, maintainable HTTP request handling.

Understanding interceptor order prevents unexpected bugs and helps design clean middleware.

6

Expert

Avoiding Common Pitfalls with Token Interceptors

🤔Before reading on: do you think interceptors can cause infinite loops if not carefully designed? Commit to your answer.

Concept: Interceptors must avoid triggering new HTTP requests that themselves get intercepted, causing loops.

If your interceptor calls an HTTP request (e.g., to refresh a token), it can cause recursion. To prevent this, exclude certain URLs or use flags to skip interception on those requests.

Result

Your app avoids crashes or freezes caused by infinite interceptor loops.

Knowing how to prevent interceptor recursion is critical for robust authentication flows.

Under the Hood

Angular interceptors work by wrapping the HttpClient's request pipeline. When you send a request, Angular passes it through each interceptor's intercept() method in sequence. Each interceptor can clone and modify the request before passing it on. Responses flow back through the interceptors in reverse order. This chain uses RxJS Observables to handle asynchronous operations smoothly.

Why designed this way?

Interceptors were designed to provide a clean, centralized way to modify HTTP requests and responses without changing every call site. This pattern follows middleware concepts from server frameworks, promoting separation of concerns and reusability. Alternatives like manually adding headers everywhere were error-prone and hard to maintain.

Client Code
   ↓
┌─────────────────────┐
│  HttpClient Request  │
└─────────────────────┘
   ↓
┌─────────────────────┐
│ Interceptor #1       │
│ (adds token header)  │
└─────────────────────┘
   ↓
┌─────────────────────┐
│ Interceptor #2       │
│ (logs request)       │
└─────────────────────┘
   ↓
┌─────────────────────┐
│  Server Receives     │
│  Modified Request    │
└─────────────────────┘
   ↑
┌─────────────────────┐
│ Interceptor #2       │
│ (logs response)      │
└─────────────────────┘
   ↑
┌─────────────────────┐
│ Interceptor #1       │
│ (processes response) │
└─────────────────────┘
   ↑
┌─────────────────────┐
│  HttpClient Response │
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do interceptors modify the original HTTP request object directly? Commit to yes or no.

Common Belief: Interceptors can change the original HTTP request object directly.

Reality: HTTP requests in Angular are immutable; interceptors must clone and modify the copy.

Why it matters: Trying to modify the original request causes runtime errors and unexpected behavior.

Quick: Do interceptors run only on successful HTTP responses? Commit to yes or no.

Common Belief: Interceptors only run on successful HTTP responses.

Reality: Interceptors run on every request and response, including errors.

Why it matters: Ignoring error responses in interceptors can cause missed opportunities for global error handling.

Quick: Can an interceptor cause an infinite loop by making HTTP calls inside itself? Commit to yes or no.

Common Belief: Interceptors can safely make HTTP calls without risk of loops.

Reality: If not carefully handled, interceptors making HTTP calls can cause infinite recursion.

Why it matters: Infinite loops crash the app and degrade user experience.

Quick: Does the order of interceptors not affect how requests are processed? Commit to yes or no.

Common Belief: Interceptor order does not matter; they run in any sequence.

Reality: Interceptor order matters; they run in the order provided for requests and reverse for responses.

Why it matters: Wrong order can cause tokens to be added too late or logging to miss data.

Expert Zone

1

Interceptors can be used to refresh expired tokens by queuing outgoing requests until a new token arrives, avoiding multiple refresh calls.

2

You can selectively apply interceptors only to certain requests by checking the request URL or headers inside interceptors.

3

Interceptors integrate deeply with Angular's RxJS pipeline, allowing complex asynchronous flows like retrying failed requests after token refresh.

When NOT to use

Avoid using interceptors for adding tokens if your app uses WebSocket or non-HTTP protocols; instead, handle authentication at the protocol level. Also, for very simple apps, manual token addition might be simpler. For complex token refresh logic, consider dedicated authentication libraries.

Production Patterns

In production, interceptors are combined with token storage services and route guards. They handle silent token refresh, global error handling (like redirecting on 401 Unauthorized), and logging. Teams often separate concerns by having one interceptor for tokens, another for error handling, and another for analytics.

Connections

Middleware in Web Servers

Interceptors are the client-side equivalent of middleware that process requests and responses.

Understanding server middleware helps grasp how interceptors chain and modify HTTP traffic in Angular.

Aspect-Oriented Programming (AOP)

Interceptors implement cross-cutting concerns like authentication, similar to AOP advice.

Knowing AOP concepts clarifies why interceptors cleanly separate concerns without cluttering business logic.

Postal Mailroom Processing

Like a mailroom clerk stamping letters, interceptors add tokens to requests automatically.

This connection helps appreciate the automation and reliability interceptors bring to request handling.

Common Pitfalls

#1 Forgetting to clone the request before adding headers.

Wrong approach:

intercept(req, next) {
req.headers.set('Authorization', 'Bearer token');
return next.handle(req);
}

Correct approach:

intercept(req, next) {
const cloned = req.clone({ headers: req.headers.set('Authorization', 'Bearer token') });
return next.handle(cloned);
}

Root cause:

Requests are immutable; modifying headers directly causes errors.

#2 Triggering HTTP calls inside interceptor without safeguards.

Wrong approach:

intercept(req, next) {
this.authService.refreshToken();
return next.handle(req);
}

Correct approach:

intercept(req, next) {
if (this.isRefreshing) {
// queue requests or skip refresh
} else {
this.authService.refreshToken().subscribe(() => {
// continue
});
}
return next.handle(req);
}

Root cause:

Calling HTTP inside interceptors can cause infinite loops if not controlled.

#3 Assuming interceptor order does not affect behavior.

Wrong approach:

providers: [
{ provide: HTTP_INTERCEPTORS, useClass: LoggingInterceptor, multi: true },
{ provide: HTTP_INTERCEPTORS, useClass: TokenInterceptor, multi: true }
]

Correct approach:

providers: [
{ provide: HTTP_INTERCEPTORS, useClass: TokenInterceptor, multi: true },
{ provide: HTTP_INTERCEPTORS, useClass: LoggingInterceptor, multi: true }
]

Root cause:

Interceptor order affects when tokens are added relative to logging or other processing.

Key Takeaways

Interceptors in Angular automatically add authentication tokens to HTTP requests, improving security and developer productivity.

Requests are immutable; interceptors must clone them to add or change headers safely.

Multiple interceptors can be chained, and their order affects how requests and responses are processed.

Careful design is needed to avoid infinite loops when interceptors trigger HTTP calls themselves.

Interceptors centralize cross-cutting concerns like authentication, error handling, and logging, making apps cleaner and more maintainable.

Practice

1. What is the main purpose of an HTTP interceptor in Angular when dealing with authentication tokens?

easy

A. To create new HTTP requests manually

B. To automatically add authentication tokens to outgoing HTTP requests

C. To block all HTTP requests from the app

D. To change the URL of HTTP requests

Solution

1. Step 1: Understand the role of interceptors

   Interceptors are used to modify HTTP requests or responses globally in Angular.

2. Step 2: Identify the use of tokens in interceptors

   They commonly add authentication tokens to requests to keep the app secure without repeating code.

3. Final Answer:

   To automatically add authentication tokens to outgoing HTTP requests -> Option B

4. Quick Check:

   Interceptors add tokens = B [OK]

Hint: Interceptors modify requests automatically, especially for tokens [OK]

Common Mistakes:

• Thinking interceptors create requests
• Believing interceptors block requests
• Assuming interceptors change URLs

2. Which of the following is the correct way to clone an HTTP request before adding an authentication token in an Angular interceptor?

easy

A. request.updateHeaders({ Authorization: 'Bearer ' + token })

B. request.headers.set('Authorization', 'Bearer ' + token)

C. request.modifyHeaders('Authorization', 'Bearer ' + token)

D. request.clone({ headers: request.headers.set('Authorization', 'Bearer ' + token) })

Solution

1. Step 1: Recall Angular HttpRequest immutability

   HttpRequest objects are immutable, so you must clone them to modify headers.

2. Step 2: Use the clone method with headers.set()

   The correct syntax is to call clone() and set the new header inside it.

3. Final Answer:

   request.clone({ headers: request.headers.set('Authorization', 'Bearer ' + token) }) -> Option D

4. Quick Check:

   Clone request with headers.set() = A [OK]

Hint: Always clone requests before changing headers [OK]

Common Mistakes:

• Trying to modify headers directly without cloning
• Using non-existent methods like modifyHeaders or updateHeaders
• Not using the clone method

3. Given this Angular interceptor code snippet, what will be the Authorization header value in the outgoing HTTP request if the token is 'abc123'?

intercept(request: HttpRequest<any>, next: HttpHandler) {
  const token = 'abc123';
  const cloned = request.clone({
    headers: request.headers.set('Authorization', `Bearer ${token}`)
  });
  return next.handle(cloned);
}

medium

A. Authorization: Bearer abc123

B. Authorization: abc123

C. Authorization: Bearer token

D. No Authorization header will be added

Solution

1. Step 1: Check how the token is added

   The code sets the Authorization header to 'Bearer ' plus the token string 'abc123'.

2. Step 2: Understand string interpolation

   The template string `Bearer ${token}` becomes 'Bearer abc123'.

3. Final Answer:

   Authorization: Bearer abc123 -> Option A

4. Quick Check:

   Header value = 'Bearer abc123' [OK]

Hint: Template strings insert token value directly [OK]

Common Mistakes:

• Forgetting 'Bearer ' prefix
• Using the literal word 'token' instead of variable
• Assuming header is not added

4. Identify the error in this Angular interceptor code that tries to add an auth token:

intercept(req: HttpRequest<any>, next: HttpHandler) {
  const token = 'xyz';
  req.headers.set('Authorization', 'Bearer ' + token);
  return next.handle(req);
}

medium

A. Headers are immutable; must clone request before setting headers

B. Token variable is not defined

C. next.handle() is missing a return statement

D. Authorization header should be lowercase

Solution

1. Step 1: Understand HttpRequest immutability

   HttpRequest headers cannot be changed directly; they are immutable.

2. Step 2: Correct way is to clone the request with new headers

   You must clone the request and set headers on the clone before passing it on.

3. Final Answer:

   Headers are immutable; must clone request before setting headers -> Option A

4. Quick Check:

   Immutable headers require cloning = A [OK]

Hint: Headers are immutable; clone request before modifying [OK]

Common Mistakes:

• Trying to set headers directly on request
• Ignoring immutability of HttpRequest
• Not returning next.handle()

5. You want to create an Angular interceptor that adds an authentication token only to requests targeting your API domain 'api.example.com'. Which approach correctly implements this conditional logic?

hard

A. Modify the token inside next.handle() without cloning

B. Add the token to all requests unconditionally

C. Check if request.url.includes('api.example.com') before cloning and adding the token

D. Use a global variable to store the token and add it after the request completes

Solution

1. Step 1: Identify the need for conditional token addition

   Only requests to 'api.example.com' should have the token added to avoid leaking tokens to other domains.

2. Step 2: Use URL check before cloning and modifying request

   Check request.url.includes('api.example.com') and then clone the request with the token header.

3. Step 3: Avoid modifying requests without cloning or adding tokens globally

   Modifying without cloning or adding tokens to all requests is insecure or incorrect.

4. Final Answer:

   Check if request.url.includes('api.example.com') before cloning and adding the token -> Option C

5. Quick Check:

   Conditional token addition by URL check = C [OK]

Hint: Add tokens only after checking request URL [OK]

Common Mistakes:

• Adding tokens to all requests blindly
• Modifying requests without cloning
• Trying to add tokens after request completes