MSAL authentication_canceled exception in .NET MAUI even when using embedded webview

Question

MSAL authentication_canceled exception in .NET MAUI even when using embedded webview

nandu kathmandi 31

Hi,

I am facing a recurring issue in a .NET MAUI Android application using MSAL 4.77.0 for Azure AD authentication.

I am seeing frequent non-fatal exceptions in Crashlytics:

Microsoft.Identity.Client.MsalClientException ErrorCode: authentication_canceled Message: User canceled authentication. On an Android device, this could be due to the lack of capabilities, such as custom tabs, for the system browser.

Scenario

Platform: .NET MAUI (.NET 9)
MSAL Version: 4.77.0
Broker: disabled (WithBroker(false))

We are using embedded webview:

  private Task<AuthenticationResult> AcquireTokenInteractive(string[] scopes)
          {
              var tcs = new TaskCompletionSource<AuthenticationResult>();
              MainThread.BeginInvokeOnMainThread(async () =>
              {
                  try
                  {
                      var authResult = await _pca.AcquireTokenInteractive(scopes)
                                          .WithParentActivityOrWindow(App.RootViewController)
                                          .WithUseEmbeddedWebView(true)
                                          .ExecuteAsync();
                      tcs.TrySetResult(authResult);
                  }
                  catch (Exception ex)
                  {
                      if (Common.MSAuthService != null && Common.DataService != null)
                      {
                          await Common.DataService.LogToAzureStorage(Common.MSAuthService, Common.LogException("AcquireTokenInteractive", ex.Message, ex.StackTrace));
                      }
                      CrashlyticsLogger.LogException("AcquireTokenInteractive", ex);
                      tcs.TrySetException(ex);
  
                  }
              });
              return tcs.Task;
          }
  _pca.AcquireTokenInteractive(scopes)
      .WithParentActivityOrWindow(parent)
      .WithUseEmbeddedWebView(true)
      .ExecuteAsync();

Observations

This happens in production for multiple users.
It appears as a non-fatal exception in Crashlytics.
Many occurrences (e.g., 300+ across ~100 users).
Users are not explicitly reporting login failure.
AuthenticationAgentActivity opens and immediately returns to MainActivity before the exception.

Additional Details

We initially added the following in MainActivity:

 protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
  {
            base.OnActivityResult(requestCode, resultCode, data);

            try
            {
                AuthenticationContinuationHelper.SetAuthenticationContinuationEventArgs(requestCode, resultCode, data);
                if (resultCallbackvalue != null)
                {
                    resultCallbackvalue(requestCode, resultCode, data);
                    resultCallbackvalue = null;
                }
            }
            catch (Exception ex)
            {
                Common.DataService.LogToAzureStorage(Common.MSAuthService, Common.LogException("OnActivityResult", ex.Message, ex.StackTrace));
                CrashlyticsLogger.LogException("OnActivityResult", ex);
            }
 }

Questions

In .NET MAUI, is AuthenticationContinuationHelper required or should it be removed entirely?
When using .WithUseEmbeddedWebView(true), can authentication_canceled still occur due to lifecycle issues?
Is .WithParentActivityOrWindow(Platform.CurrentActivity) recommended in MAUI, or should MSAL auto-detect the activity?
What is the recommended configuration for stable MSAL authentication in .NET MAUI Android?
Is there any known issue with MSAL 4.77.0 on Android 13+ that could trigger this behavior?

I want to understand:

if there is a lifecycle/configuration issue in MAUI

And how to prevent unnecessary authentication_canceled exceptions in production logs

Any guidance on best practices for MSAL + .NET MAUI Android authentication would be appreciated.

2 answers

Your answer

Answer 1

Jack Dang (WICLOUD CORPORATION) 14,955 Microsoft External Staff Moderator

Hi @nandu kathmandi ,

Thanks for reaching out.

It looks like the authentication_canceled exceptions you’re seeing are most likely caused by how the Android activity lifecycle interacts with MSAL in .NET MAUI, rather than actual user cancellations. Even with .WithUseEmbeddedWebView(true), MSAL still launches a temporary AuthenticationAgentActivity, and if that activity is destroyed or not correctly tied to a stable parent, MSAL interprets it as the user canceling.

The users aren't noticing these failures, which is worth investigating carefully. MSAL does not automatically retry silently after an authentication_canceled - a canceled interactive flow leaves nothing new in the token cache, so any immediate silent call would just fail again with user_interaction_required.

The more likely explanation is that AcquireTokenInteractive is being called proactively somewhere in your app - on app resume, during page navigation, or as part of a background token check - rather than only in direct response to a user-initiated sign-in. In that case, the cancellation happens before the user even sees a login screen, so they never notice it, and the next attempt succeeds because the timing or lifecycle state is different by then.

I'd audit where AcquireTokenInteractive is being triggered across your app to confirm it's only called from explicit user actions.

Just to set expectations, MSAL will report authentication_canceled for any incomplete interactive flow, including:

A fast back-press
The activity being destroyed during a redirect
Timing mismatches in the lifecycle

I suggest the following recommendations (you can treat these as a reference while verifying what applies best to your app):

Use the current Android activity as the parent for MSAL calls:

.WithParentActivityOrWindow(Platform.CurrentActivity)

This is generally safer than passing App.RootViewController and avoids lifecycle mismatches.

Remove AuthenticationContinuationHelper if you’re using embedded webview, as it’s typically not required in modern MAUI apps and can sometimes introduce unnecessary handling, as confirmed in this MSAL GitHub issue.

While this is a non- Microsoft link, it is a official repository maintained by Microsoft.

Make sure only one interactive authentication call runs at a time and avoid triggering it during page transitions or navigation events.
Optional but helpful: set your MainActivity launch mode to SingleTask to reduce the chance of activity recreation during auth.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

nandu kathmandi 31

@Jack Dang (WICLOUD CORPORATION) Thank you for your detailed explanation — that insight was very helpful.

I reviewed the application flow and audited where AcquireTokenInteractive is triggered. It is not called directly from a sign-in button alone. Instead, it can be invoked indirectly through GetAccessToken() in the following scenarios:

if (Connectivity.NetworkAccess == NetworkAccess.Internet)
{
    await _msAuthService.GetAccessToken();
    await Common.GetProfileDetails(...);
    await GetAnnouncements();
}

In ViewModelBase constructor: via WeakReferenceMessenger and OnNavigatedFrom

WeakReferenceMessenger.Default.Register<RefreshAccessTokenMessage>(this, (recipient, message) =>
{
    _msAuthService.GetAccessToken();
});

ViewModelBase.cs OnNavigatedFrom() Unregister the RefreshAccessTokenMessage

 public virtual void OnNavigatedFrom(INavigationParameters parameters)
        {
          	     WeakReferenceMessenger.Default.Unregister<RefreshAccessTokenMessage>(this);
            AppConstants.PageToNavigate = string.Empty;
        }

App.xml.cs file OnSleep:

 protected async override void OnSleep()
        {
            base.OnSleep();
            WeakReferenceMessenger.Default.Unregister<RefreshAccessTokenMessage>(this);
            await 
        }

So whenever RefreshAccessTokenMessage is published, it may trigger interactive auth if silent acquisition fails.

InSide GetAccessToken

If AcquireTokenSilent() throws MsalUiRequiredException, we fall back to:

public async Task<bool> GetAccessToken()
        {
            // Gets the available accounts
            var accounts = await _pca.GetAccountsAsync();

            // Stores first account available
            Common.Account = accounts.FirstOrDefault();

            if (Common.Account != null)
            {
                try
                {
                    // This call acquires the access token silently without asking for user credentials
                    var authResult = await _pca.AcquireTokenSilent(Configurations.Scopes, Common.Account).ExecuteAsync();

                    // Stores the access token
                    AppConstants.AccessToken = authResult.AccessToken;

                    return true;
                }
                catch (MsalUiRequiredException ex)
                {
                    ///add exception logging
                }
            }
            // Interactive auth needed - ensure we're on UI thread for the entire operation
            var interactiveResult = await InvokeOnMainThreadAsync(() =>
                PerformInteractiveAuthenticationAsync(Configurations.Scopes));

            if (interactiveResult != null)
            {
                AppConstants.AccessToken = interactiveResult.AccessToken;

                await GetHttpContentWithTokenAsync(interactiveResult.AccessToken);

                // Handle iOS cookie capture
                if (DeviceInfo.Platform == DevicePlatform.iOS)
                {
                    AppConstants.OauthCookie = _cookieStore.CurrentCookies
                        .FirstOrDefault(cc => cc.Name == "stsservicecookie");
                }

                Common.Account = interactiveResult.Account;
                return true;
            }

            return false;
        }


private async Task<T> InvokeOnMainThreadAsync<T>(Func<Task<T>> action)
        {
            TaskCompletionSource<T> tcs = new TaskCompletionSource<T>();

            MainThread.BeginInvokeOnMainThread(async () => {
                try
                {
                    var result = await action();
                    tcs.SetResult(result);
                }
                catch (Exception ex)
                {
                    if (Common.MSAuthService != null && Common.DataService != null)
                    {
                       await Common.DataService.LogToAzureStorage(Common.MSAuthService, Common.LogException("InvokeOnMainThreadAsync", ex.Message, ex.StackTrace));
                    }
                    CrashlyticsLogger.LogException("InvokeOnMainThreadAsync", ex);
                    tcs.SetException(ex);
                }
            });

            return await tcs.Task;
        }

Crashlytics shows authentication_canceled.
Logs indicate AuthenticationAgentActivity opens and immediately returns to MainActivity.
The next token attempt usually succeeds.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Jack Dang (WICLOUD CORPORATION) 14,955 Reputation points Microsoft External Staff Moderator

2026-02-23T09:16:17.1833333+00:00

Hi @nandu kathmandi ,

Thanks for your feedback.

If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.
nandu kathmandi 31 Reputation points

2026-02-24T08:12:55.55+00:00
Hi @Jack Dang (WICLOUD CORPORATION) ,

Thank you for your response.

At this point, the issue is not fully resolved yet.

Based on your earlier explanation, I reviewed our implementation and confirmed that AcquireTokenInteractive() may be triggered indirectly during page initialization when AcquireTokenSilent() fails. This happens because we call GetAccessToken() on multiple pages to ensure the token remains valid when the app resumes from background.
I used this GetAccessToken in all the pages when network is down and user get the popup and click TryAgain it will execute

if (Connectivity.NetworkAccess == NetworkAccess.Internet) { IsBusy = false; if (_msAuthService != null && _graphService != null) { await _msAuthService.GetAccessToken(); await Common.GetProfileDetails(_msAuthService, _graphService); GetNotifications(); } }

However, we are still observing frequent authentication_canceled exceptions in production (non-fatal), even though users are not reporting visible login interruptions.

I would like to clarify the correct recommended approach:

Should AcquireTokenInteractive() be strictly limited to explicit user-initiated actions only?

If AcquireTokenSilent() fails during page load or app resume, should we avoid automatically falling back to interactive and instead prompt the user manually?

What is the recommended pattern in .NET MAUI for maintaining session validity when the app comes back from background?

We want to align with the official MSAL best practices and prevent unintended lifecycle-triggered cancellations.

Looking forward to your guidance.
Jack Dang (WICLOUD CORPORATION) 14,955 Reputation points Microsoft External Staff Moderator

2026-02-24T11:03:20.25+00:00
Hi @nandu kathmandi ,

Thanks for the detailed follow-up.

Based on what you described, the frequent authentication_canceled exceptions are very likely caused by automatically triggering AcquireTokenInteractive() when AcquireTokenSilent() fails during page load, resume, or retry flows. In .NET MAUI Android, interactive auth is sensitive to lifecycle timing, and if it runs while the activity is still stabilizing, MSAL may treat the interruption as a cancellation.

In your current implementation, since GetAccessToken() is invoked from multiple pages and also inside retry flows (such as when the user taps Try Again after connectivity is restored), this increases the chance that interactive authentication is triggered during navigation or lifecycle transitions. That timing overlap is very likely what’s leading to the frequent authentication_canceled logs you’re seeing.

You can take a look at these links for reference:

https://learn.microsoft.com/en-us/entra/msal/dotnet/getting-started/best-practices

https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/mobile-applications

To answer your questions directly:

Should AcquireTokenInteractive() be strictly limited to explicit user-initiated actions only?

Yes, AcquireTokenInteractive() should ideally be limited to explicit user-initiated actions.

If AcquireTokenSilent() fails during page load or app resume, should we avoid automatically falling back to interactive and instead prompt the user manually?

If AcquireTokenSilent() fails with MsalUiRequiredException, it’s better not to auto-fallback to interactive during lifecycle events. Instead, prompt the user and let them initiate sign-in.

What is the recommended pattern in .NET MAUI for maintaining session validity when the app comes back from background?

For session management on resume, try silent only. If it fails, mark the session as needing re-authentication and handle it in a controlled way.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
nandu kathmandi 31 Reputation points

2026-02-25T05:49:40.32+00:00
Thank you for your response @Jack Dang (WICLOUD CORPORATION) ,

I would like to provide more details.

I am observing logs in Firebase Crashlytics where many users are getting a non-fatal exception with the same pattern.

Observed Flow:

SplashActivity → MainActivity → AuthenticationAgentActivity → MainActivity

Method: AcquireTokenInteractive

Exception: MsalClientException

ErrorCode: authentication_canceled

Exception message:

User canceled authentication. On an Android device, this could be due to the lack of capabilities, such as custom tabs, for the system browser.

The same exception is also occurring in:

Method: GetApiAccessToken

ErrorCode: authentication_canceled

Additional Observations:

Around 73% of affected devices are Samsung devices

The exception is logged as non-fatal

Users are not explicitly reporting that they canceled authentication

Current Implementation:

Every time the app opens and the Home Page loads, I am calling:

await _msAuthService.GetAccessToken();

As per my requirement:

If the user logs in

And does not open the app for 2 days

The session expires by default

When the user opens the app again, it prompts for login

However, I am seeing this authentication_canceled exception frequently in Crashlytics.

Could this be happening because:

The interactive login is being triggered automatically?

The system browser (Custom Tabs) is not available or being killed?

Samsung battery optimization/background restrictions?

The app is resuming from background state?

I would appreciate your guidance on how to properly handle this scenario and avoid this frequent authentication_canceled logging.

Thank you.
Jack Dang (WICLOUD CORPORATION) 14,955 Reputation points Microsoft External Staff Moderator

2026-03-04T09:03:36.0433333+00:00
Hi @nandu kathmandi ,

Could this be happening because the interactive login is being triggered automatically?

I think this is the most likely explanation for what you're seeing. When GetAccessToken() is called on every home page load and AcquireTokenSilent() fails - which it will after a 2-day session expiry - your code immediately falls back to AcquireTokenInteractive(). The problem is that at the moment the home page loads, Android's activity stack is still transitioning from SplashActivity to MainActivity. Launching AuthenticationAgentActivity during that unstable window gives MSAL no choice but to treat it as a cancellation, because the activity it attached to is no longer in a stable foreground state. The Microsoft documentation on acquiring tokens interactively specifically notes that interactive auth must be initiated from a live, fully resumed foreground activity.

Could this be happening because the system browser (Custom Tabs) is not available or being killed?

I see what you mean about this, but since you're using .WithUseEmbeddedWebView(true), Custom Tabs are not involved in your flow. The embedded webview is self-contained, so browser availability on the device is not a factor here.

Could this be happening because of Samsung battery optimization/background restrictions?

I understand why the 73% Samsung figure looks suspicious, but I'd attribute that to Samsung's market share in your user base rather than a Samsung-specific restriction. Battery optimization would affect background processes, but your auth flow is triggered in the foreground during page load - so that's unlikely to be the direct cause.

Could this be happening because the app is resuming from background state?

This is closely related to the first point. When the app resumes after 2 days, the activity lifecycle goes through a full restart sequence. Triggering AcquireTokenInteractive() before MainActivity has fully settled into a resumed state is what's producing the AuthenticationAgentActivity -> MainActivity bounce you're seeing in Crashlytics.

To address this properly, I'd suggest separating silent and interactive auth into two distinct flows:

// Called automatically on page load / app resume — silent only, no fallback private async Task TryRefreshTokenSilently() { var accounts = await _pca.GetAccountsAsync(); var account = accounts.FirstOrDefault(); if (account == null) { // No account found — surface a sign-in prompt, don't auto-launch interactive IsSessionExpired = true; return; } try { var authResult = await _pca .AcquireTokenSilent(Configurations.Scopes, account) .ExecuteAsync(); AppConstants.AccessToken = authResult.AccessToken; } catch (MsalUiRequiredException) { // Session expired — notify the UI to show a re-auth prompt // Do NOT call AcquireTokenInteractive here IsSessionExpired = true; } } // Only called when the user explicitly taps "Sign In" — never automatically public async Task SignInInteractively() { try { var authResult = await _pca .AcquireTokenInteractive(Configurations.Scopes) .WithParentActivityOrWindow(Platform.CurrentActivity) // use this, not App.RootViewController .WithUseEmbeddedWebView(true) .ExecuteAsync(); AppConstants.AccessToken = authResult.AccessToken; Common.Account = authResult.Account; } catch (MsalClientException ex) when (ex.ErrorCode == "authentication_canceled") { // User backed out — handle gracefully, no need to log as a fatal event } }

For session management on app resume specifically, Microsoft's mobile applications guidance recommends the same pattern: attempt silent only on resume, and reserve interactive for explicit user-initiated flows.

I hope this gives you a clear enough direction to move forward.

Given that the root cause points to the lifecycle timing of when AcquireTokenInteractive() is called, the implementation details from here will depend on how your app's navigation and state management are structured, so your team would be best placed to adapt this to fit your specific setup.

If you run into new issues after making these changes, feel free to open a new thread with the updated behavior and logs.

Answer 2

AuthenticationContinuationHelper: In .NET MAUI, AuthenticationContinuationHelper is generally used to handle the continuation of authentication after the user returns from the authentication activity. It is recommended to keep it in your OnActivityResult method to ensure that the authentication flow is properly handled. Removing it may lead to issues where the authentication result is not processed correctly.
Embedded WebView and authentication_canceled: Yes, even when using .WithUseEmbeddedWebView(true), the authentication_canceled exception can still occur. This can happen if the user navigates away from the authentication process or if there are lifecycle issues that cause the authentication activity to be interrupted.
Using .WithParentActivityOrWindow(Platform.CurrentActivity): It is generally recommended to specify the parent activity explicitly using .WithParentActivityOrWindow(Platform.CurrentActivity). While MSAL can auto-detect the activity, explicitly setting it can help avoid issues related to activity context, especially in complex applications.
Recommended Configuration: For stable MSAL authentication in .NET MAUI Android, ensure that:
- You are handling the authentication continuation properly in OnActivityResult.
- You are using the correct version of MSAL that is compatible with your target framework.
- You have a fallback mechanism for handling cases where authentication fails or is canceled.
- Monitor the logs for any specific patterns that might indicate lifecycle issues or user behavior leading to cancellations.
Known Issues with MSAL 4.77.0 on Android 13+: There may be specific issues related to MSAL 4.77.0 on Android 13+, particularly regarding how the embedded web view interacts with the system browser capabilities. It's advisable to check the MSAL GitHub repository or documentation for any reported issues or updates regarding this version and platform compatibility.

To prevent unnecessary authentication_canceled exceptions in production logs, consider implementing better error handling and user feedback mechanisms. This could include informing users about the need for a compatible browser or providing clear instructions on how to complete the authentication process without interruptions.

Share via

MSAL authentication_canceled exception in .NET MAUI even when using embedded webview

Scenario

Observations

Additional Details

Questions

2 answers

Your answer