MSAL Interceptor unable to find cached token issued from custom OIDC server

[alamfsmb]

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.37.0

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

2.5.7

Public or Confidential Client?

Public

Description

We are trying to use the MSAL angular library in OIDC protocol mode with a custom OIDC server but having trouble using the MSAL interceptor.

Shortly after logging in, when I trigger an HTTP request that activates the MSAL interceptor, the trace logs show that acquireTokenSilent is rejected and it tries to acquire by redirect, but this happens every time the interceptor is activated and the HTTP request is never actually made. Not sure if it is a problem with our implementation client side or maybe if the OIDC server is not compliant. I can see all the tokens in local storage, but the interceptor seems to not capture them and I think it may relate to failure to check the authority meta data.

MSAL Configuration

auth: {
      protocolMode: ProtocolMode.OIDC,
      clientId: 'testApp', 
      authority: 'https://localhost:44334',
      knownAuthorities: ["https://localhost:44334"],
      redirectUri: '/auth',
      authorityMetadata: JSON.stringify({
        authorization_endpoint:"https://localhost:44334/connect/authorize",
        token_endpoint:"https://localhost:44334/connect/token",
        issuer: "https://localhost:44334",
        end_session_endpoint: "https://localhost:44334/connect/logout",
      })
    },
    cache: {
      cacheLocation: BrowserCacheLocation.LocalStorage,
      storeAuthStateInCookie: isIE
    },
    system: {
      loggerOptions: {
        loggerCallback(_logLevel: LogLevel, message: string) {
          console.log(message);
        },
        logLevel: LogLevel.Trace,
        piiLoggingEnabled: false
      }
    }

Relevant Code Snippets

When the app comes back from the redirect, we subscribe to the MsalBroadcast service to ensure an active account.


   let activeAccount = this.msalService.instance.getActiveAccount();
    if(!activeAccount && this.msalService.instance.getAllAccounts().length > 0){
      activeAccount = this.msalService.instance.getAllAccounts()[0];
      this.msalService.instance.setActiveAccount(activeAccount);
    }

### Identity Provider

Other

### Source

External

[tnorling]

@alamfsmb Can you please share Trace level MSAL logs so we can help you debug? It's worth also mentioning that we do not have explicit support for any 3rd party identity providers. We'll do our best to unblock you by pointing you in the right direction but if fixes are needed on MSAL they're unlikely to be prioritized, it would likely fall on you to open a pull request with the changes. Just FYI.

[alamfsmb]

Appreciate you taking a look for us! We understand there isn't official support, but hope we can still take advantage of this library. I've attached the logs generated after initiating the API call matching with our configured protectedResourceMap. We don't have custom scopes so I just included the default scopes in the configuration.

  {
      provide: MSAL_INTERCEPTOR_CONFIG,
      useValue: {
        interactionType: InteractionType.Redirect,
        protectedResourceMap: new Map([
          ["https://localhost:44309/api/*", ["openid", "profile", "offline_access"]],
        ])
      }
    }

console-MSAL.log

[tnorling]

@alamfsmb Thanks, can you email me the contents of localStorage? Please remove the "secret" field from the access and refresh token entries before sending.

[tnorling]

I'm thinking this may be due to the uppercase 'A' in your clientId. It looks like our credential filters are not normalizing case, which is a bug on us. Can you try with an all lowercase clientId and see if that works? If you can confirm, I'll mark this as a bug and add it to our backlog.

[alamfsmb]

@tnorling Oh that is a good thought - I didn't consider that, but unfortunately it did not resolve it trying just now, and I had an all lowercase clientId before sending this example too. I think it is failing on the matchEnvironment filter because the trace doesn't output BrowserCacheManager.getAuthorityMetadata: at any point, but I couldn't debug why it would fail to get authorityMetadataKeys

[tnorling]

One other thing I'm noticing is that your knownAuthorities array has https:// in it. It's not supposed to be there, but MSAL should be stripping that off anyway...Try removing it. Otherwise I don't see anything obviously wrong here, it may just be a matter of stepping through a debugger. Unfortunately without being able to repro with your custom authority on my end, I'll have to leave that to you to report back your findings :/

[alamfsmb]

I should've tried that first, my apologies! The issue was just not defining the jwks_uri in the authorityMetadata. Thanks for all your help!