HTTP Interceptor: Attach token optionally

[felixfiskare]

Describe the problem you'd like to have solved

Currently I can only decide if I always or never want a token to be attached to a request. I'm not aware of a way to have a token attached to a request if the user is authenticated and to send the request without a token if the user is not authenticated.
This is a problem for Endpoints which serve content to authenticated and un-authenticated users.

Describe the ideal solution

The ideal solution would be for the interceptor to wait till initial authentication procedure is finished and then continue dispatching requests with a token or without.

Alternatives and current work-arounds

My current workaround is a interceptor which calls getAccesssTokenSilently() and adds a token upon success or no token upon error but dispatches the request in both cases. This is not ideal (because I can't just observe the accesstoken), but it works.

Additional context

Other people seem to have the same usecase as me: https://community.auth0.com/t/auth0-angular-http-interceptor-error-when-user-is-not-logged-in/50866/3

[frederikprijck]

Hi @felixfiskare ,

Thanks for reporting this.
I am curious to understand what you mean here:

My current workaround is a interceptor which calls getAccesssTokenSilently() and adds a token upon success or no token upon error but dispatches the request in both cases. This is not ideal (because I can't just observe the accesstoken), but it works.

Why are you saying this isnt ideal? How are u seeing the optional attachement of a token if not doing it that way?
I think that should work fine.

I also think that, baking this optionallity into the SDK might result in unexpected behavior for other people, as I think other people might want to react to a request that was supposed to attach a token but couldnt because the user wasnt authenticated, and not just fire off the request without a token. An example here could be to redirect to Auth0 to re-authenticate in the event that this should happen (see Handling errors in our readme at .https://github.com/auth0/auth0-angular/blob/master/README.md)

Therefor I think, for these specific use-cases, you should be fine rolling your own interceptor that extends ours, ensuring it only calls our interceptor when being able to retrieve a token. This should be doable using something along the lines of:

@Injectable()
export class CustomAuthHttpInterceptor extends AuthHttpInterceptor {
  constructor(
    private configFactory: AuthClientConfig,
    private authService: AuthService
  ) {
  super(configFactory, authService);
}

  intercept(
    req: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    return this.authService.getAccessTokenSilently().pipe(
      mergeMap(() => super.intercept(req, next)),
      catchError(() =>  next.handle(req))
    );
  }
}

Would something like this work for you?

[felixfiskare]

From the docs I had the impression, that getAccessTokenSilently() would trigger a new call to auth0 and not cache the accesstoken. Therefore this approach would result in unnecessary calls to auth0. Am I mistaken?

[frederikprijck]

getAccessTokenSilently only does a call to Auth0 if there is no token available or the token is expired (you can also pass it a property to bypass the cache, but thats disabled by default).
You can also rely on the value of the user$ or isAuthenticated$ observable, however this can have the sideeffect that there is no user locally, while getAccessTokenSilently would be perfectly able to get a new token because of either an existing session with Auth0 or because of the existence of a Refresh Token.

There for I would say using getAccessTokenSilently is a good idea, it is the same call we use in our interceptor. The fact that you woud be calling this in your interceptor as well doesnt mean we would do two calls.
In case there is no token yet, your interceptor will retrieve a token and our interceptor would use that token from the cache.

[stevehobbsdev]

@felixfiskare By default, getAccessTokenSilently() will cache the token for you and use that for subsequent requests. In the event that the access token is about to expire, a call will be made to Auth0 to fetch a new one and keep the token valid on your behalf.

Also by default, the access token will be cached in memory, meaning that if you refresh the page, a call to Auth0 will be made to try and get a new valid access token.

You can disable this behaviour by passing ignoreCache: true to this method but again that's not the default behaviour. Otherwise, if you are seeing calls to Auth0 for every call of getAccessTokenSilently, please check that you are not using an extraordinarily short expiry time on your access tokens (< 60 seconds).

Hope that helps!

[felixfiskare]

Thank you two for your valuable feedback!
I think the approach to extend AuthHttpInterceptor works for me.
There is only a minor problem: configFactory and authService are private in AuthHttpInterceptor and therefore not accessible for me. I had to rename authService in CustomAuthHttpInterceptor for it to be accessible inside intercept()

I also remember why I thought getAccessTokenSilently() is not caching. user$ emits a new value every time getAccessTokenSilently() is called. Funnily, I found an issue yesterday regarding this behavior and an explanation from one of you why it does that.

[frederikprijck]

There is only a minor problem: configFactory and authService are private in AuthHttpInterceptor and therefore not accessible for me. I had to rename authService in CustomAuthHttpInterceptor for it to be accessible inside intercept()

Oops, yes... My bad, sorry.

I also remember why I thought getAccessTokenSilently() is not caching. user$ emits a new value every time getAccessTokenSilently() is called. Funnily, I found an issue yesterday regarding this behavior and an explanation from one of you why it does that.

Yep we are aware of this and are considering how to solve that problem.

Closing this issue, feel free to continue conversation tho! Whenever needed, we can always reopen.

[felixfiskare]

Just a small update: Using this piece of code resulted in every failed network request to be send again without a token. catchError not only catches errors inside getAccessTokenSilently, but also errors in super.intercept (for example any http call error)

intercept(
req: HttpRequest,
next: HttpHandler
): Observable<HttpEvent> {
return this.authService.getAccessTokenSilently().pipe(
mergeMap(() => super.intercept(req, next)),
catchError(() => next.handle(req))
);
}
}

My workaround looks like this:

intercept(
    req: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    return this._authService.getAccessTokenSilently().pipe(
      catchError(() => of(true)),
      // getAccessTokenSilently returns a string
      // if the value of errorOccurred is a boolean true, then an error has occured and the request continues without an authorization header
      mergeMap(errorOccurred => errorOccurred === true ?
        next.handle(req)
        : super.intercept(req, next)),
    );

[neildodson]

This way seems to work for me:

Register the Auth0 Interceptor and your custom interceptor in Angular DI:

  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: OptionalJwtInterceptor,
      multi: true
    },
    ...
    {
      provide: AuthHttpInterceptor
    },
    provideHttpClient(withInterceptorsFromDi())
  ],

Then take the Auth0 interceptor as a dependency and forward to it if the user is supposed to be logged in:

import { HttpEvent, HttpHandler, HttpInterceptor, HttpRequest } from '@angular/common/http'
import { Injectable } from '@angular/core'
import { AuthHttpInterceptor, AuthService } from '@auth0/auth0-angular'
import { mergeMap, Observable, take } from 'rxjs'

@Injectable({ providedIn: 'root' })
export class OptionalJwtInterceptor implements HttpInterceptor {
  constructor(
    private auth0Interceptor: AuthHttpInterceptor,
    private auth0Service: AuthService
  ) {}

  public intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (!this.allowsAnonymous(req.url)) {
      return this.auth0Interceptor.intercept(req, next)
    } else {
      return this.auth0Service.isAuthenticated$.pipe(
        take(1),
        mergeMap((isAuthenticated) =>
          isAuthenticated ? this.auth0Interceptor.intercept(req, next) : next.handle(req)
        )
      )
    }
  }

  private allowsAnonymous(endpoint: string): boolean {
   // optionally specify which endpoints you are allowing mixed authenticated/unathenticated calls to
    return true 
  }
}

In my case, I additionally have to catch the condition where the user is "logged in" but their refresh token has expired. In this case, I just call loginWithRedirect() again, which ensures, silently or via a new login form, that the user is logged in and the site reloaded:

import { Injectable } from '@angular/core'
import { Router } from '@angular/router'
import { AuthService, GenericError } from '@auth0/auth0-angular'

@Injectable({ providedIn: 'root' })
export class HealthCheckService {

  constructor(
    private authService: AuthService,
    private router: Router,
  ) {
    this.authService.error$.subscribe((authError) => {
      console.log(authError)
      var redirect = this.getRedirectFromError(authError as GenericError)
      this.router.navigate([redirect])
    })
  }

  private getRedirectFromError(error: GenericError): string {
    if (error.error === 'invalid_grant' && error.message == 'Unknown or invalid refresh token.') {
      return 'log-in' //calls authService.loginWithRedirect()
    } else return 'log-out' //calls authService.logOut()
  }
}