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


  • msal@1.x.x or @azure/msal@1.x.x
  • @azure/msal-browser@2.0.2
  • @azure/msal-angular@0.x.x
  • @azure/msal-angular@1.x.x
  • @azure/msal-angularjs@1.x.x




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”:“",“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]


  • Is this issue security related?


  • 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: '',
    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.


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

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 20 (10 by maintainers)

Most upvoted comments

@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

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.