CODEWITHSUNDEEP
angularangular-http-interceptorsmsal-angularangular-token
Vlad B.
Vlad B.

Reputation: 2917

MSAL Angular HTTP interceptor for localhost not attaching token

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?

Upvotes: 16

Views: 18061

Answers (4)

bluefox
bluefox

Reputation: 156

We encountered a similar issue where the Bearer token wasn't being attached to the HttpClient when running the application locally.

Initially, we configured the ProtectedResourceMap using a wildcard:

const protectedResourceMap = new Map<string, Array<string>>();
protectedResourceMap.set('*', ['custom api scope']);

This worked fine with azure/msal-angular v2, but when we upgraded to v3, we found that it required a more specific configuration. Instead of using '*', specifying the full API URL pattern resolved the issue. For example:

const protectedResourceMap = new Map<string, Array<string>>();
protectedResourceMap.set('https://localhost:5001/api/*', ['custom api scope']);

This change allowed the Bearer token to be correctly attached to the requests.

I hope this helps others facing the same issue!

Upvotes: 1

Lewis Cianci
Lewis Cianci

Reputation: 1065

Similar to SETI At Home's answer, here's how to do it without calling add on the protectedResourceMap. It's actually a lot easier overall.

  protectedResourceMap: new Map([
    ['https://graph.microsoft.com/v1.0/me', ['user.read']],
    ['/api/', ["api://your-app-guide-would-be-here/And.The.Claim"]],
  ])

Using /api/ seems to authenticate any requests with api in them, which in my case, works really well. I was previously specifying the full http://appsite.local/api, which was causing the problem.

Upvotes: 2

Vlad B.
Vlad B.

Reputation: 2917

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'
]);

Upvotes: 21

aolszowka
aolszowka

Reputation: 1390

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

Upvotes: 2

Related Questions