Microsoft-authentication-library-for-js: No 'Access-Control-Allow-Origin' header is present on the requested resource - when silently acquiring token

[don1989]

Library

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

Framework

If you are using a framework, please provide the framework and version (e.g. Angular v8, React v16, etc).
react: ^16.12.0
react-aad-msal: ^2.3.4
I am using a template created from create react app using typescript.
I am using the react aad wrapper for msal. https://www.npmjs.com/package/react-aad-msal

Description

When logging in and authenticating with fresh cookies/cache, the web app is able to authenticate and log in with no problems. However, when it is time refresh the login token trying to silently authenticate, the web app fails to login and it fails to redirect to authenticate again, with the following warnings/errors in the console below.

Note: This does not happen when using an incognito window.

Note that I've checked the related existing issues and none seem to remedy the issue I'm experiencing.

Warning:

A cookie associated with a cross-site resource at http://login.microsoftonline.com/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Warning:

DevTools failed to parse SourceMap: https://[my-website].azurewebsites.net/static/css/main.95606285.css.map
[my-website].azurewebsites.net/:1 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://login.microsoftonline.com/[my-tenant-id]/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2F[my-website].azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=f73862c4-903c-4615-8e0c-a0b8d6c8345c&scope=openid+profile+email&response_mode=form_post&nonce=4a335e2defee4efaa6b6f74db1e1e60f_20200227105101&state=redir%3D%252Fstatic%252Fjs%252Fmain.36ffb3df.js with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

Error:

[my-website].azurewebsites.net/:1 Access to manifest at 'https://login.windows.net/[my-tenant-id]/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2F[my-test-website].azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=f73862c4-903c-4615-8e0c-a0b8d6c8345c&scope=openid+profile+email&response_mode=form_post&nonce=7e222b39ae9148f88c75019477a0e654_20200227105102&state=redir%3D%252Fmanifest.json' (redirected from 'https://[my-test-website].azurewebsites.net/manifest.json') from origin 'https://[my-test-website].azurewebsites.net' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Error:

login.windows.net/[my-tenant-id]/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2F[my-test-website].azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=f73862c4-903c-4615-8e0c-a0b8d6c8345c&scope=openid+profile+email&response_mode=form_post&nonce=7e222b39ae9148f88c75019477a0e654_20200227105102&state=redir%3D%252Fmanifest.json:1 GET https://login.windows.net[my-tenant-id]/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2F[my-test-website].azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=f73862c4-903c-4615-8e0c-a0b8d6c8345c&scope=openid+profile+email&response_mode=form_post&nonce=7e222b39ae9148f88c75019477a0e654_20200227105102&state=redir%3D%252Fmanifest.json net::ERR_FAILED

Warning

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://login.microsoftonline.com/[my-tenant-id]/oauth2/authorize?response_type=code+id_token&redirect_uri=https%3A%2F%2F[my-test-website].azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=f73862c4-903c-4615-8e0c-a0b8d6c8345c&scope=openid+profile+email&response_mode=form_post&nonce=853d2aaa6b7248208aae03ff2b6b6716_20200227105102&state=redir%3D%252Fbrowser-icon.ico with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for

Security

No

Regression

Yes

Configuration

Please provide your MSAL configuration options.

export const authProvider = new MsalAuthProvider(
    {
      auth: {
        authority: "https://login.microsoftonline.com/[my_tenant_id]",
        clientId: "[my_client_id]",
        // After being redirected to the "redirectUri" page, should user
        // be redirected back to the Url where their login originated from?
        navigateToLoginRequestUrl: false,
        postLogoutRedirectUri: window.location.origin,
        redirectUri: window.location.origin,
      },
      cache: {
        cacheLocation: "localStorage",
        storeAuthStateInCookie: true
      },
      // Enable logging of MSAL events for easier troubleshooting.
      // This should be disabled in production builds.
      system: {
        logger: new Logger(
          (logLevel, message, containsPii) => {
            console.log("[MSAL]", message);
          },
          {
            level: LogLevel.Verbose,
            piiLoggingEnabled: false
          }
        )
      },

    },
    {
      scopes: ["openid"]
    },
    {
      loginType: LoginType.Redirect,
      // When a token is refreshed it will be done by loading a page in an iframe.
      // Rather than reloading the same page, we can point to an empty html file which will prevent
      // site resources from being loaded twice.
      tokenRefreshUri: window.location.origin + "/auth.html"
    }
  );

Reproduction steps

1. Deploy your production build to a server and login
2. Wait until the token has expired and you need to log back in
3. Notice That it fails to silently authenticate with the following warnings/errors

Expected behavior

The web app should log-in without errors.

Browsers

Occurs in Chrome and Edge

Any help or assistance with this issue would be greatly appreciated. Please let me know if you need any more information.

[jasonnutter]

@don1989 The urls that you provided are urls that look to be for the Auth Code flow, not the implicit flow (e.g. response_type=code+id_token). The version of msal you are using uses the Implicit Flow. Is your application enabled for Implict Flow in the Azure Portal? https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-app-registration#enable-the-implicit-flow

[don1989]

Hi @jasonnutter we do have Implicit Flow enabled. Please see the attached screenshot below of our configuration in the Azure Portal

[jasonnutter]

@don1989 Do you have a Fiddler trace you can share with me? That would be helpful. Email is in my profile, thanks!

[don1989]

@jasonnutter I've sent across the Fiddler trace via email. Let me know here/via email if you need any more info.

[jasonnutter]

@don1989 Thanks! The issue is that your auth.html page is setup to require authentication, which results in a redirect to the login screen inside the hidden iframe, which causes the error you are observing. The fix is that your auth.html page must not itself require authentication, to prevent this redirect.

[don1989]

Hi @jasonnutter not sure what you mean that the auth.html page is setup to require authentication. The auth.html page is just a blank file in the public folder as suggested by the react-aad-msal package. It's not a route that's wrapped in the authentication layer as far as I'm aware on the code side.

Does the file need to be marked in some way to ignore authentication or is it something that needs to be toggled in the portal? How would I know it's been setup to require authentication?

[jasonnutter]

@don1989 If I go to your /auth.html route in an incognito window, I get redirected to the login screen. So yes, this route needs to be marked in your app code so that it doesn't trigger this redirect (which is what is causing the error you are seeing), as it looks like your whole app has been setup to require auth.

[don1989]

I see now, thanks for your help and patience @jasonnutter. It turns out we had 'Log in with Azure Active Directory' enabled in our Authentication Azure portal options which forced the entire app to require authentication. The fix was to set it to Allow Anonymous requests so it didn't wrap the auth.html in authentication:

Thanks for your assistance.