Microsoft-authentication-library-for-js: Msal fails to get access token with "Token renewal operation failed due timeout: Token Renewal Failed."

[bpcastilho]

When issuing a new token to do a call to an custom API sometimes we get the error: "Token renewal operation failed due timeout: Token Renewal Failed."

Msal verbose logs:
I S-Verbose renewing accesstoken
I S-Verbose renewToken is called for
I S-lnfo Add msal frame to document:msaIRenewFramehttps://tenant.onmicrosoft.com/dev/read
-Verbose Renew token Ex#cted state: ...
-Verbose Set loading state to pending for: https://tenant.onmicrosoft.com/dev/read
I S-lnfo LoadFrane: msaIRenewFramehttps://tenant.onmicrosoft.com/customAPI/read
I S-lnfo Add msal frame to docunent:msaIRenewFramehttps://tenant.onmicrosoft.com/dev/read
I S-Verbose Loading frame has timed out after: 6 seconds for scope https_L&tenant.onmicrosoft.com/dev/read

This is being returned by:
private loadIframeTimeout(urlNavigate: string, frameName: string, scope: string): void {

([https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/cf14220e2ec440e2402d026a80ca699b947ce1a0/src/UserAgentApplication.ts])

Questions:

1. We want to know why we're get this timeout.
2. Foreach time we're calling "acquireTokenSilent" we're getting a new token isn't MSAL caching the tokens?

[4deeptech]

I have run into the exact same issues, along with some others (trying to use Angular 5) I would have thought it would use the expiration time in the token and keep using the same one found locally until the time runs out and then goes out to grab a new one. The timeout issue...not sure what that is but I have seen that and decided to just use some custom logic to grab the token out of the storage area and use that directly for the time being. Not a production app so not hurting me at the moment.

My biggest issue at the moment is trying to use the redirect style logins in an angular app. This app will be run on mobile devices and the popup thing would be a bad user experience...that is unless the redirect is worse. Any idea when any of the PR's will be addressed and a new release cut?

[spottedmahn]

Hey @bpcastilho - have you seen this thread: #209? And this thread: #258?

[spottedmahn]

Foreach time we're calling "acquireTokenSilent" we're getting a new token isn't MSAL caching the tokens?

Set your loadFreameTimeout to something much larger (like 30s). If you don't get timeout errors, are you sure it is not pulling from cache? If so, can you post the msal log?

[spottedmahn]

My biggest issue at the moment is trying to use the redirect style logins in an angular app

Hey @4deeptech - why not use loginPopup then?

[4deeptech]

@spottedmahn I have considered that but the user experience on a mobile device would suck. Plus you have issues with popup blockers etc.

[haagOS]

I am having the same issue.
I have an angular 1.6 sample app attached with a readme on how to install and setup everything needed to run the app. The app allows to login with a local account as well as a facebook account. Further we acquire tokens for 2 different APIs. We use the latest msal.js version from npm which is 0.1.5.

We are using Azure AD B2C with Identity Framework Experience (Preview). The setup process of the policies is also described in the readme.
We set the access_token lifetime to 5 minutes which results in getting a new access_token for every call of AcquireTokenSilent(...). We use this setting in our sample to provoke the error.

Steps to reproduce the error (as described in readme):

1. Open developer tools to see console output.
2. Login with a local account (not facebook). You will get an id token.
3. Call Acquire Token silently either for API1 or API2 or for both in parallel.
4. Check console output.
5. Repeat steps 3) and 4) until there is a message in console output like: Loading frame has timed out after: 60 seconds for scope [https://...]

The error seems to occur randomly without any indication for about 1% - 5% of all request to acquire a token. As you can see, we set the 'loadFrameTimeout' parameter to 60 seconds. However this does not resolve the error.

AngularApp.zip

[bpcastilho]

This is solved on the Dev branch!

[mjrcmrma]

I still see this issue with msal-angular 1.0.2

[rudolphdewet]

In my case this happened because the route that the iframe was redirecting to, did not inject MsalService, and was not guarded, so it was never instantiated and thus never picked up the new token from the iframe.

I didn't want that route guarded, so I just inject MsalService into the constructor of the component to ensure it is instantiated.

It seems like something that would happen often though, as in my case I was clicking through from the home component (not guarded) to a guarded component.

[jacksonhart]

In my case this happened because the route that the iframe was redirecting to, did not inject MsalService, and was not guarded, so it was never instantiated and thus never picked up the new token from the iframe.

I didn't want that route guarded, so I just inject MsalService into the constructor of the component to ensure it is instantiated.

It seems like something that would happen often though, as in my case I was clicking through from the home component (not guarded) to a guarded component.

life saved.
adding a bit of logic into the root component of an angular app (unguarded) produced this error.
needed to inject msalService.

some more docs about this would be good or did I miss it.

[hilarudeens]

In my case this happened because the route that the iframe was redirecting to, did not inject MsalService, and was not guarded, so it was never instantiated and thus never picked up the new token from the iframe.

I didn't want that route guarded, so I just inject MsalService into the constructor of the component to ensure it is instantiated.

It seems like something that would happen often though, as in my case I was clicking through from the home component (not guarded) to a guarded component.

In my case this happened because the route that the iframe was redirecting to, did not inject MsalService, and was not guarded, so it was never instantiated and thus never picked up the new token from the iframe.

I didn't want that route guarded, so I just inject MsalService into the constructor of the component to ensure it is instantiated.

It seems like something that would happen often though, as in my case I was clicking through from the home component (not guarded) to a guarded component.

rudolphdewet commented on 14 Nov 2018 you are right.

I have gone further in to msal-angular...

MSAL renew token via iframe and expect acquireTokenSilent call from inside iframe
By this time, MSAL updates localstorage against iframe-requestId.
Eg: msal.token.renew.status9c490d12-49c6-4179-9015-aad285cc45c2: Completed

If you are not call this acquireTokenSilent from iframe which is result of redirectUrl's page, then iframe-requestId left as msal.token.renew.status9c490d12-49c6-4179-9015-aad285cc45c2: In Progress
and it never update access token in storage.

So you will get Token renewal operation failed due timeout: Token Renewal Failed.. No matter what big UserAgentApplication.loadFrameTimeout value you have.

UserAgentApplication.prototype.loadIframeTimeout = function (urlNavigate, frameName, scope) {
   // ...
        setTimeout(function () {

           // Storagte still have below state...
           // msal.token.renew.status9c490d12-49c6-4179-9015-aad285cc45c2: In Progress

            if (_this._cacheStorage.getItem(Constants_1.Constants.renewStatus + expectedState) === Constants_1.Constants.tokenRenewStatusInProgress) {
                // fail the iframe session if it"s in pending state
                _this._logger.verbose("Loading frame has timed out after: " + (_this.loadFrameTimeout / 1000) + " seconds for scope " + scope + ":" + expectedState);
                if (expectedState && window.callBackMappedToRenewStates[expectedState]) {
                   // Throws token renewal error from here...
                    window.callBackMappedToRenewStates[expectedState]("Token renewal operation failed due to timeout", null, "Token Renewal Failed", Constants_1.Constants.accessToken);
                }
                _this._cacheStorage.setItem(Constants_1.Constants.renewStatus + expectedState, Constants_1.Constants.tokenRenewStatusCancelled);
            }
        }, this.loadFrameTimeout);
    };