How to Generate the Correct OneDrive OAuth Token in ServiceNow

If your ServiceNow instance keeps uploading files into the wrong OneDrive folder, it means the OAuth token was issued for the wrong Microsoft account. This is the exact procedure to generate a correct token for the right service account, using a manually configured OAuth Application Registry — the approach behind a custom-built OneDrive integration rather than ServiceNow's official OneDrive Spoke.

A note on scope before starting: this procedure applies specifically to a custom OAuth setup built around a System OAuth Application Registry entry, which relies on the delegated permissions model — the same mechanics covered in this blog's companion articles on why ServiceNow needs two Microsoft identities, and why uploads land in the wrong folder in the first place. If your integration instead runs through ServiceNow's official Microsoft OneDrive Spoke, authentication is typically managed through its own Connection & Credential Alias — often set up with a certificate-based application identity rather than a delegated user session — and this specific token-regeneration procedure won't apply the same way. Confirm which of the two you're actually running before following the steps below.

Prerequisites

• OneDrive service account
• Azure AD (Entra ID) admin account, for App Registration
• OneDrive OAuth profile configured in ServiceNow
• Valid Client ID and Client Secret

Why This Procedure Is Necessary

With SSO environments:

• VDI login automatically logs users into Microsoft.
• Teams/Outlook auto-start with cached credentials.
• Office apps silently authenticate.

This means clicking Get OAuth Token will always use whatever Microsoft session is active — even if you logged into ServiceNow with a different account.

Step-by-Step Procedure

Step 1 — Completely Log Out of All Microsoft Sessions

You must remove all cached Microsoft identity data:

• Sign out of Teams.
• Sign out of Outlook.
• Stop the OneDrive sync client.
• Close Office apps.
• Log out of Office.com.
• Clear browser cookies.
• Restart the browser.
• Optionally, reboot the VDI session.

Step 2 — Open a New Incognito Window

Do not use a normal window — normal windows share cookies from the VDI session you just tried to clear.

Step 3 — Sign In to Microsoft Manually With the OneDrive Account

In the incognito window:

• Go to https://login.microsoftonline.com.
• Sign in as the OneDrive service account.
• Complete MFA if required.

At this stage, Microsoft knows the identity that should receive the OAuth token.

Step 4 — Log In to ServiceNow With the Same Service Account

Still in the same incognito window:

• Log in to ServiceNow as the OneDrive service account.
• Do not use impersonation — impersonation only changes the ServiceNow-side identity, not the Microsoft session behind it.

Step 5 — Navigate to the OneDrive OAuth Profile

Go to:

System OAuth → Application Registry → Your OneDrive OAuth Profile

Step 6 — Click "Get OAuth Token"

This time:

• Microsoft sees the OneDrive service account as the active session.
• Microsoft issues the OAuth token for the OneDrive service account.
• ServiceNow stores the token under the OneDrive service account's user context.

Step 7 — Validate the Token

Run a test action against your configured OneDrive integration — for example, a Create Folder action. The folder should appear under the OneDrive service account's OneDrive path, not any other account's.

What If It Still Shows the Wrong Account?

Then the VDI or OS-level Microsoft session is still active. Use one of these options:

• Try a different browser.
• Use an entirely different machine.
• Use a private Windows account profile.
• Disable Teams auto-login temporarily.
• Use a clean VM with no corporate SSO session.

Once the correct token is captured, normal usage will no longer rely on the end user's Microsoft session — the token, once correctly issued, stays valid independent of whoever's logged into Windows or Teams afterward.

If You're Doing This Often, Consider the Structural Fix

This procedure works, but it's worth being honest about what it actually is: a careful manual workaround for a session-dependent authentication model. If this keeps recurring — a token needs regenerating every time someone's VDI session changes, or every time a service account's cached credentials expire — that's a signal worth acting on, not just repeating the fix for. Moving to ServiceNow's official Microsoft OneDrive Spoke, configured with a certificate-based application identity rather than delegated permissions, removes the session dependency at its root. See this blog's companion article on wrong-folder uploads for the specific setup details, including the Sites.Selected scoping option that keeps the application's access appropriately limited rather than organization-wide.

Summary

To ensure ServiceNow writes files into the correct OneDrive folder:

• The OneDrive service account must be the active Microsoft identity when generating the OAuth token.
• Logging in to ServiceNow as that same service account ensures correct token storage.
• Clearing cached Microsoft sessions is essential in SSO environments.

Following these steps guarantees the OAuth token belongs to the correct storage account every time — and if you find yourself following them often, that's the cue to look at the Spoke-based alternative instead of treating this as a permanent routine.