MSAL : Azure B2C Blazor wasm fails after 24 hours when the refresh token has been expired

[kiranchandran]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We are using Azure B2C login with a Blazor wasm application. Using local storage to save the tokens and the goal is not to ask user credentials again if the user tries to access the same site till the refresh token expires. This works well.

But we are facing an issue if we try to access the application after a period of 24 hours of inactivity. This is the time when the refresh token expires(SPA with PKEC in azure B2C has 24 hour expiry for refresh token). After 24 hours the application is trying to login the user through a hidden iframe and for some security reason some of the browsers are throwing a warning and the login process fails.

I can see below message in the console
An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.

I need to know is there any way to fix this. Does MSAL in Blazor provides any customization to disable this hidden iframe and enable the normal browser redirect?

Here is my configuration in program.cs

builder.Services.AddMsalAuthentication(options =>
{
    options.ProviderOptions.LoginMode = "redirect";
    builder.Configuration.Bind("AzureAdB2C", options.ProviderOptions.Authentication);
    options.ProviderOptions.DefaultAccessTokenScopes.Add("SomeScope");
    options.ProviderOptions.Cache.StoreAuthStateInCookie = true;
    options.ProviderOptions.Cache.CacheLocation = "localStorage";
    options.UserOptions.RoleClaim = ClaimTypes.Role;
});

Here are some screenshots from the browser console which can help to understand the issue better.

In case if someone needs to re-create this issue without waiting for 24 hours, then you can replace the access token and refresh token to an already expired value and try this in Chrome Incognito or Mozilla. In normal chrome I am not getting this issue, but some other are getting the issue even in non incognito chrome window.

Expected Behavior

The application should have with some kind of a fallback strategy. Let say if the browser doesn't support hidden iframe redirect, then define a fallback mechanism to do a regular browser redirect.

Steps To Reproduce

Login to Azure B2C
Use local storage to store the token cache in client side
Try to load the application again after 24 hours(ie after the refresh token expires)
See the browser logs

Note: In case if someone needs to re-create this issue without waiting for 24 hours, then you can replace the access token and refresh token to an already expired value and try this in Chrome Incognito or Mozilla. In normal chrome I am not getting this issue, but some other are getting the issue even in non incognito chrome window.

Exceptions (if any)

In the chrome console windows we can see a warning like
An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.

In the redirect response we can see an error like
error=interaction_required&error_description= AADB2C90077 User does not have an existing session and request prompt parameter has a value of None

.NET Version

7

Anything else?

No response

[mkArtakMSFT]

@jmprieur do you know who can help with this one? This is related to msal.js library.
Also, is there some other place the customer should report this issue in? Thanks!

[mkArtakMSFT]

Ping @jmprieur

[kiranchandran]

Hi @jmprieur,

Is this something that you can help us?

Thanks

[mkArtakMSFT]

Discussed this with current @EmLauber (her team owns MSAL.js).
@EmLauber feel free to unassign yourself if you find out that this is caused by Blazor, rather than MSAL.js (which is the current thinking). Thanks!

[hectormmg]

@kiranchandran @mkArtakMSFT It seems like MSAL.js is working as designed.

The iframe warning is not a breaking error, it is expected for some cases and handled by MSAL by throwing an interaction required error. Per MSAL JS docs, applications using MSAL need to add fallback code to catch interaction required errors and call acquireTokenRedirect/Popup.

From aspnetcore/src/Components/WebAssembly/Authentication.Msal/src/Interop/AuthenticationService.ts:

async getAccessToken(request?: AccessTokenRequestOptions): Promise<AccessTokenResult> {
        try {
            this.trace('getAccessToken', request);
            const newToken = await this.getTokenCore(request?.scopes);
            return {
                status: AccessTokenResultStatus.Success,
                token: newToken
            };
        } catch (e) {
            return {
                status: AccessTokenResultStatus.RequiresRedirect
            };
        }
    }

I see getAccessToken returns a RequiresRedirect status, so I assume somewhere up the MsalAuthentication service there must be fallback logic, but I can't find it.

Here's a modified version of getTokenCore that shows more or less what MSAL usage usually looks like:

Also from aspnetcore/src/Components/WebAssembly/Authentication.Msal/src/Interop/AuthenticationService.ts

async getTokenCore(scopes?: string[]): Promise<AccessToken | undefined> {
        const account = this.getAccount();
        if (!account) {
            throw new Error('Failed to retrieve token, no account found.');
        }

        const silentRequest = {
            redirectUri: this._settings.auth?.redirectUri,
            account: account,
            scopes: scopes || this._settings.defaultAccessTokenScopes
        };

        this.debug(`Provisioning a token silently for scopes '${silentRequest.scopes}'`)
        this.trace('_msalApplication.acquireTokenSilent', silentRequest);
        // const response = await this._msalApplication.acquireTokenSilent(silentRequest); < --- Current acquireTokenSilent call
        
        ### Expected usage
        
        const response = await this._msalApplication.acquireTokenSilent(silentRequest).then(tokenResponse => {
            // Do something with the tokenResponse
        }).catch(error => {
            if (error instanceof InteractionRequiredAuthError) {
            // fallback to interaction when silent call fails
            return msalInstance.acquireTokenRedirect(request);
        }

      ### End expected usage

        this.trace('_msalApplication.acquireTokenSilent-response', response);

        if (response.scopes.length === 0 || response.accessToken === '') {
            throw new Error('Scopes not granted.');
        }

        const result = {
            value: response.accessToken,
            grantedScopes: response.scopes,
            expires: response.expiresOn
        };

        this.trace('getAccessToken-result', result);

        return result;
    }

My assumption is the current implementation was chosen so ASP.NET Core can delegate the decision of falling back to redirect to the developer, which makes sense. Are there any developer docs for the MsalAuthentication service I can look at to see if the usage pattern is correct?

[kiranchandran]

Hi @mkArtakMSFT Thanks a lot for the follow up.
Hi @hectormmg I am looking for an option within the framework to disable this iframe and always use the re-direct or popup. From the browser warning, it looks like at some point we need to get rid of this hidden iframe for security reasons.

As of now, as a temporary fix we have edited the AuthenticationService.js and loading it in the balzor from within the application. But I think we need to have an overriding feature from the framework itself.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[hectormmg]

@kiranchandran @mkArtakMSFT MSAL Browser does have a configuration option called CacheLookupPolicy that can be configured per-request. Using CacheLookupPolicy.AccessTokenAndRefreshToken will return the InteractionRequired error before attempting iframe renewal. Example:

var silentRequest = {
    scopes: ["SCOPE"],
    account: currentAccount,
    forceRefresh: false
    cacheLookupPolicy: CacheLookupPolicy.AccessTokenAndRefreshToken // will default to CacheLookupPolicy.Default if omitted
};

[kiranchandran]

Hi @hectormmg,

We are using blazor and could you please let me know how exactly this can be configured?

Thanks