Microsoft-authentication-library-for-js: Interaction required error not thrown after refresh token expires

[deasems]

Library

• [ ] [email protected] or @azure/[email protected]
• [x] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]

Framework

N/A

Description

I'm testing out long lived sessions and I'm occasionally seeing token requests fail in an unexpected way.

If an access token request fails because the refresh token had expired I expected MSAL to make an SSO request to get a new refresh token and complete the access token request. If the SSO request fails I expect to get an interaction required error. Correct me if I misunderstood MSAL's intended behavior in these scenarios.

The problematic behavior I'm seeing happens when requesting an access token and the refresh token has expired and MSAL rejects the access token request with a 'monitor_window_timeout' error and doesn't seem to attempt to do a SSO request to maintain a session.

Error Message

The error received from the AAD authority:

{"error":"invalid_grant","error_description":"AADSTS700081: The refresh token has expired due to maximum lifetime. The token was issued on 2020-08-24T08:18:06.0651014+00:00 and the maximum allowed lifetime for this application is 1.00:00:00.\r\nTrace ID: 614af246-b80e-4fa2-8f01-1fca19228300\r\nCorrelation ID: 78ded38e-e196-4a40-9c38-87bef83480b5\r\nTimestamp: 2020-08-25 08:34:12Z","error_codes":[700081],"timestamp":"2020-08-25 08:34:12Z","trace_id":"614af246-b80e-4fa2-8f01-1fca19228300","correlation_id":"78ded38e-e196-4a40-9c38-87bef83480b5","error_uri":"https://login.microsoftonline.com/error?code=700081","suberror":"bad_token"}

The error MSAL.js produces:

{"errorCode":"monitor_window_timeout","errorMessage":"Token acquisition in popup failed due to timeout.","name":"BrowserAuthError","message":"monitor_window_timeout: Token acquisition in popup failed due to timeout.","stack":"BrowserAuthError: monitor_window_timeout: Token acquisition in popup failed due to timeout.\n at BrowserAuthError.AuthError [as constructor]

Security

• [ ] Is this issue security related?

Regression

• [ ] Did this behavior work before?
  Version:

MSAL Configuration

new PublicClientApplication({
    auth: {
      authority: getAuthorityUrl(authorityEnv),
      clientId: process.env.CLIENT_ID,
      navigateToLoginRequestUrl: false,
      redirectUri: window.location.origin,
      postLogoutRedirectUri: 'https://microsoft.com',
    },
    cache: {
      cacheLocation: 'localStorage',
    },
    system: {
      loggerOptions: {
        piiLoggingEnabled: process.env.NODE_ENV === 'development',
        logLevel: LogLevel.Info,
      },
    },
  });

Reproduction steps

I've generally seen MSAL maintain sessions over multiple days so I'm not sure what scenario causes it to get into the state where it throws this error

Expected behavior

If MSAL can't maintain a session I'd expect to get an interaction required error so I can inform the user.

Browsers/Environment

• [ ] Chrome
• [ ] Firefox
• [x] Edge
• [ ] Safari
• [ ] IE
• [ ] Other (Please add browser name here)

[deasems]

Looking at the browser logs, here's some more info I found related to this issue. Prior to the request that produced the error logs above I see this error when requesting a token:

https://login.microsoftonline.com/common/oauth2/v2.0/token net::ERR_NAME_NOT_RESOLVED

Maybe this error put MSAL into a state where it displayed the errors in my original post for subsequent requests?

Our app refreshes a token when the user comes online (ie window.addEventListener('online', /* do refresh */)) so perhaps we need to wait a bit after that event for the network to be fully functional to avoid this error. Regardless I wouldn't expect the error behavior I originally reported.

[jmckennon]

If an access token request fails because the refresh token had expired I expected MSAL to make an SSO request to get a new refresh token and complete the access token request. If the SSO request fails I expect to get an interaction required error. Correct me if I misunderstood MSAL's intended behavior in these scenarios.

This is correct and the intended behavior. You should receive an interaction_required error if your refresh token is expired.

I'll be trying to reproduce this today as what you're seeing could definitely be a bug.

[jmckennon]

@deasems I was able to reproduce a timeout when I call acquireTokenSilent when I both had an invalid refresh token AND while disconnected from the internet, which is likely what you're seeing here. I think that your hunch is also likely correct, so can you try waiting for a second or two after the user goes online in your app to make the network/token calls?

We'll look to see how this scenario is handled in the library, as the timeout error is not very informative of the actual problem.

[deasems]

Thanks for confirming @jmckennon. An improvement to how MSAL handles this scenario would be very appreciated. We looked into the online status browser APIs and they don't guarantee internet connectivity so we'd need a fairly elaborate implementation to ensure we avoid this avoid this scenario completely.

[thoo1]

@deasems I was able to reproduce a timeout when I call acquireTokenSilent when I both had an invalid refresh token AND while disconnected from the internet, which is likely what you're seeing here. I think that your hunch is also likely correct, so can you try waiting for a second or two after the user goes online in your app to make the network/token calls?

We'll look to see how this scenario is handled in the library, as the timeout error is not very informative of the actual problem.

I'd also like more information if possible for this monitor_window_timeout error, in the code it looks like it can either resolve with the token or reject with this error, but it'd like to know why it didn't resolve on this line https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/2c75dcfdc3af95ce942433d950ceb95de085c3da/lib/msal-browser/src/interaction_handler/SilentHandler.ts#L73

Currently if this doesnt resolve, the interval keeps running until it resolves or times out

[jmckennon]

@thoo1 Unfortunately, due to the same-origin policy in the browser, we don't have a way to know why an iframe times out (we cannot programmatically inspect the contents of the iframe if it's on a different origin, such as login.microsoftonline.com).

[sameerag]

@deasems Can you please test with the latest browser release and help us if the issue is still seen? There are some improvements we made which may have mitigated this issue. Please share the steps and logs in case you are able to reproduce this.

[deasems]

@sameerag I've setup a build using 2.7.0 and will check in on a long running session this week to see if I run into the issue

[szalapski]

I seem to be getting this same situation as @deasems in the original question (I'm getting an "invalid_grant" error with AADSTS700081), and my internet connection is just fine. In fact, if I reload the page, I get the same error over and over. How do I configure MSAL to make us redirect to prompt the user to sign in, in this case, rather than getting a HTTP 400 error and thus a fatal error in my site? (I am on Blazor WebAssembly on .NET 5 with Microsoft.AspNetCore.Identity 2.2.0 and Microsoft.AspNetCore.Components.Authorization 5.0.0)

For what it's worth, we think this is happening in AuthorizeView Blazor component, while it is "authorizing".

[jasonnutter]

@szalapski Apologies for the delay. I see you potentially have a workaround, but if you have a Fiddler trace you can share (email in my profile), that would be appreciated. MSAL.js should catch and attempt to handle invalid_grant errors in this scenario (returning an interaction_required error at worst), so this could be a bug in the library.

[szalapski]

I anticipate having the problem manifest on Monday, so I'll try to grab a fiddler trace then.

[szalapski]

I think I refreshed my tokens over the weekend, so it didn't happen today.

Are you concerned that the fix in https://github.com/dotnet/aspnetcore/issues/28151 won't be good enough for this?

[jasonnutter]

I think I refreshed my tokens over the weekend, so it didn't happen today.

Are you concerned that the fix in dotnet/aspnetcore#28151 won't be good enough for this?

I would like to make sure if this is a bug in MSAL that it gets properly fixed, given not everyone uses Blazor WebAssembly.

[szalapski]

Ah, I see. I'll try to get a fiddler capture next Monday.

On Mon, Dec 14, 2020 at 2:56 PM Jason Nutter [e-mail]
wrote:

I think I refreshed my tokens over the weekend, so it didn't happen today.

Are you concerned that the fix in dotnet/aspnetcore#28151
https://github.com/dotnet/aspnetcore/issues/28151 won't be good enough
for this?

I would like to make sure if this is a bug in MSAL that it gets properly
fixed, given not everyone uses Blazor WebAssembly.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/2219#issuecomment-744705210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUY5MOOTXSPBBCBT7UB37LSUZ3WXANCNFSM4QRB3YWQ
.

[szalapski]

The problem unexpectedly happened today. I will send you the Fiddler capture.

[github-actions[bot]]

This issue has not seen activity in 14 days. It will be closed in 7 days if it remains stale.

[szalapski]

I am curious if there is any update. Probably not over the holidays; thanks either way.

[github-actions[bot]]

This issue has not seen activity in 14 days. It will be closed in 7 days if it remains stale.