MSAL Angular HTTP interceptor for localhost not attaching token

14.1k Views Asked by At

I'm trying to call a localhost API and to attach the bearer token on the header. It should be done by msal-angular automatically. For now, I have added the localhost API route to the protectedResourceMap but there is no bearer token inside the header. Tried to add jsonplaceholder and graph.microsoft to make an HTTP post call to it and it works. The only issue is when I try to make an HTTP call to localhost API.

I'm using:

@azure/[email protected]
@azure/[email protected]

I have used factory providers for the interceptors in the app.module.ts.

export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
  const protectedResourceMap = new Map<string, Array<string>>();
   protectedResourceMap.set('https://graph.microsoft.com/v1.0/me', [
     'user.read',
   ]);

  protectedResourceMap.set('http://localhost:5000/api/add', [
    'api://custom api consent'
  ]);

   protectedResourceMap.set('https://jsonplaceholder.typicode.com/', [
     'api://custom api consent'
   ]);

  return {
    interactionType: InteractionType.Redirect,
    protectedResourceMap,
  };
}

It is also registered in the app.module.ts:

    providers: [
        {
          provide: HTTP_INTERCEPTORS,
          useClass: MsalInterceptor,
          multi: true,
        },
        {
          provide: MSAL_INSTANCE,
          useFactory: MSALInstanceFactory,
        },
        {
          provide: MSAL_GUARD_CONFIG,
          useFactory: MSALGuardConfigFactory,
        },
        {
          provide: MSAL_INTERCEPTOR_CONFIG,
          useFactory: MSALInterceptorConfigFactory,
        },
        MsalService,
        MsalGuard,
        Msal,
        BroadcastService,
  ],

Any suggestions?

2

There are 2 best solutions below

4
On BEST ANSWER

If you're having trouble with a similar issue, I found a solution that may help. It turns out that using the protectedResourceMap function more dynamically and providing a relative URL works better. The problem was caused by using the full route, including the domain name and port number, such as "http://localhost:4200/api/add". The solution was simply to add "/api/" to the protectedResourceMap like this:

protectedResourceMap.set('/api/', [
'api://custom api consent'
]);
0
On

We were struggling with @Bozhinvski's answer above; specifically what api://custom api consent meant.

This value needs to be aligned with the Application ID URI, which by convention is in the format of api://<Application (client) ID> where the Application (client) ID is usually the GUID generated for you by Azure. However this is not a hard requirement (but is the default when generated and what is recommended). This can be controlled in the Azure Active Directory Portal under the Application Registration Page -> Expose an API and can be changed if you wish:

Application ID URI