Silent authentication fails with MS Graph OneNote API using InteractiveBrowserCredential (SSO) – WAM error for some users

Question

Dear Microsoft Support,

We are encountering an issue related to OneNote access via Microsoft Graph API in our organization’s internal application.

📘 Background

Our company actively uses shared OneNote notebooks in Microsoft 365 for internal documentation and workflow coordination. An in-house application integrates with these notebooks via Microsoft Graph API to automate content creation, update existing pages, and analyze information.

Until recently, our application utilized Application permissions to access OneNote resources. However, following Microsoft's deprecation of Application-level access to OneNote content, we have migrated to using Delegated authentication (on-behalf-of users) with InteractiveBrowserCredential and silent SSO-based authentication to minimize user disruption.

⚠️ Issue Description

SSO (silent authentication) works correctly for many users. However, several users—particularly those working on Windows Server 2016 and Windows Server 2019—consistently encounter authentication failures, requiring manual interaction each time the application attempts to access OneNote via Graph API.

We also encountered the same issue with one user on Windows Server 2022, even though SSO works for others on the same OS. These affected users are signed in with Microsoft 365 accounts and use two-factor authentication (MFA). In some cases, users do not have direct access to their passwords due to company policy, and authentication is handled by our IT department.

Diagnostics show the following in affected environments:

• WamDefaultSet: ERROR during token acquisition

Failure of InteractiveBrowserCredential with error: User canceled authentication even though the user has an active session in Edge/Office

AzureADJoined state may vary, but SSO works on some machines even when it is NO

✅ What Works

The same application and authentication flow succeed for most users.

Users on some Windows Server 2022 environments successfully authenticate silently.

🔍 What We Need

Is there any way to obtain an exception or enable Application-level access to OneNote for our tenant or registered application?

If Application permissions are not possible:

Could the inconsistent SSO behavior be related to Azure AD user/device configuration, Conditional Access, PRT/WAM state, or specific domain policies?

  Are there any recommended configurations or prerequisites that ensure consistent silent authentication via WAM/PRT on server-based environments?
  

We would appreciate your guidance on how to proceed, including any known limitations of WAM or MSAL authentication under Windows Server editions.

We are ready to provide logs, test results, and user environment details if required.

Thank you for your assistance.Dear Microsoft Support,

We are encountering an issue related to OneNote access via Microsoft Graph API in our organization’s internal application.

📘 Background

Our company actively uses shared OneNote notebooks in Microsoft 365 for internal documentation and workflow coordination. An in-house application integrates with these notebooks via Microsoft Graph API to automate content creation, update existing pages, and analyze information.

Until recently, our application utilized Application permissions to access OneNote resources. However, following Microsoft's deprecation of Application-level access to OneNote content, we have migrated to using Delegated authentication (on-behalf-of users) with InteractiveBrowserCredential and silent SSO-based authentication to minimize user disruption.

⚠️ Issue Description

SSO (silent authentication) works correctly for many users. However, several users—particularly those working on Windows Server 2016 and Windows Server 2019—consistently encounter authentication failures, requiring manual interaction each time the application attempts to access OneNote via Graph API.

We also encountered the same issue with one user on Windows Server 2022, even though SSO works for others on the same OS.
These affected users are signed in with Microsoft 365 accounts and use two-factor authentication (MFA). In some cases, users do not have direct access to their passwords due to company policy, and authentication is handled by our IT department.

Diagnostics show the following in affected environments:

WamDefaultSet: ERROR during token acquisition

Failure of InteractiveBrowserCredential with error: User canceled authentication even though the user has an active session in Edge/Office

AzureADJoined state may vary, but SSO works on some machines even when it is NO

✅ What Works

The same application and authentication flow succeed for most users.

Users on some Windows Server 2022 environments successfully authenticate silently.

🔍 What We Need

Is there any way to obtain an exception or enable Application-level access to OneNote for our tenant or registered application?

If Application permissions are not possible:

Could the inconsistent SSO behavior be related to Azure AD user/device configuration, Conditional Access, PRT/WAM state, or specific domain policies?

  Are there any recommended configurations or prerequisites that ensure consistent silent authentication via WAM/PRT on server-based environments?
  

We would appreciate your guidance on how to proceed, including any known limitations of WAM or MSAL authentication under Windows Server editions.

We are ready to provide logs, test results, and user environment details if required.

Thank you for your assistance.

Answer 1

Hello Artom,

Thanks for posting question on Microsoft Forum.

Application Permissions for OneNote

As of March 31, 2025, Microsoft officially deprecated Application-level access to OneNote via Microsoft Graph API. There is currently no supported exception process to re-enable app-only access—even for trusted tenants. Delegated authentication is now the only supported method.

🧩 Silent SSO Issues on Windows Server

Your issue aligns closely with a known scenario where WAM-based silent authentication fails on certain Windows Server environments, even when the user has an active session. This is often due to:

Missing or invalid Primary Refresh Token (PRT)

WAM misconfiguration or outdated components

AzureADJoined = NO, which can still work in some cases but is not reliable

Conditional Access policies that block silent token acquisition under certain conditions

You can find a nearly identical case described on Microsoft Q&A, which mirrors your environment and symptoms.

✅ Recommendations

To improve consistency across environments:

1. Ensure PRT is issued: Use dsregcmd /status to verify PRT presence. If missing, check if the device is Azure AD joined or hybrid joined.
2. Update WAM components: Ensure the latest Windows updates are installed, especially on Server 2016/2019, where WAM support is less robust.
3. Review Conditional Access policies: Look for policies that may block legacy auth or require compliant devices.
4. Enable Web Account Manager (WAM) logging: This can help pinpoint token acquisition failures.
5. Consider using IntegratedWindowsAuthenticationCredential for domain-joined environments, if feasible.

Hope this helps.

If the answer is helpful, please click Accept Answer and kindly upvote it. If you have any further questions about this answer, please click Comment