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.

Understanding ServiceNow + OneDrive Integration: Why Two Microsoft Accounts Are Required

Integrating ServiceNow with Microsoft OneDrive often confuses teams — especially when they realize two different roles are involved, sometimes represented by two different Microsoft accounts:

1. The identity that ends up owning the uploaded files (the OneDrive/runtime identity)
2. The Entra ID administrative identity used to configure the integration itself

Why does this split exist, and — this is the part most explanations skip — is it actually unavoidable? Let's break it down, including the architecture that avoids the split entirely.

1. The Runtime Identity — Where Files Actually Land

This is the identity that actually owns the files ServiceNow uploads. When ServiceNow pushes a document to OneDrive, it goes to the personal or shared folder belonging to whichever identity's OAuth token ServiceNow is holding at the time.

This identity represents where the documents live — not who configured the integration.

2. The Entra ID Admin Identity — Configuring the Integration

The Entra ID (formerly Azure AD) administrative account is used only for configuring the integration. This account:

• Creates the App Registration
• Generates the Client ID
• Creates and rotates the Client Secret
• Grants Microsoft Graph API permissions
• Approves admin consent

This account does not store documents and doesn't represent a file-owning user on the OneDrive side — it only provides the OAuth infrastructure the integration runs on.

Worth being precise about: both of these are Microsoft Entra ID identities under the hood — there isn't a separate "OneDrive account" type distinct from an Entra ID account. The real distinction is about role in the OAuth flow: one identity does one-time administrative setup, and a separate identity's session (in one specific architecture, covered next) determines where files actually land at runtime.

3. Why This Split Exists — In the Delegated Permissions Model Specifically

This is the detail that changes everything about how to think about this problem: the two-identity split described above is a real, well-documented consequence of delegated permissions — one of two permission models Microsoft Graph API supports for OneDrive access — not an unavoidable fact about ServiceNow+OneDrive integration in general.

In the delegated model, the app calls Microsoft Graph on behalf of a signed-in user. Two identities genuinely participate: a real user who consents to delegate their access, and the application (via its Entra ID registration) that receives temporary delegated access to act within that user's permissions. The application's effective permissions are the intersection of what it's been granted and what that specific signed-in user is actually allowed to do — it can never exceed the user's own access.

Function	Requires	Why
OAuth application setup	Entra ID admin account	Creates the App Registration and grants permissions
File upload destination	Runtime user session	Delegated tokens act within that specific user's own OneDrive

4. The Most Common Confusion in Organizations

Many teams mistakenly think:

"We updated the client secret in ServiceNow, but OneDrive still uploads into the wrong user's folder."

This happens because, under the delegated model:

• The Entra ID credentials control the application's identity and permissions.
• The Microsoft session of whoever last completed the OAuth consent ("Get OAuth Token") flow controls which OneDrive the files actually land in.

Rotating a client secret doesn't touch the second part at all — the upload destination is tied to whichever user's session generated the currently-held delegated token, and that can silently be a different person than whoever the team assumes "owns" the integration.

5. The Alternative: Application Permissions (No Second Identity Required)

This is the option worth strongly considering if the delegated model's session-dependent behavior has already caused confusion, or if a predictable, admin-controlled upload destination matters more than convenience of setup.

Microsoft Graph also supports application permissions (via the OAuth Client Credentials grant), where the app acts under its own identity — no signed-in user involved at all. With application permissions like Files.ReadWrite.All, the target user or site is specified explicitly in the API path (for example, /users/{userPrincipalName}/drive or /sites/{siteId}/drive), rather than being implicitly determined by whoever's session token happens to be active.

This directly eliminates the confusion described in Section 4: there's no "whoever clicked Get OAuth Token" ambiguity, because the destination isn't session-dependent at all — it's whatever your integration explicitly specifies, every time, consistently.

The tradeoff: application permissions are broader by nature — a permission like Files.ReadWrite.All at the application level can potentially reach any user's files in the organization, so admin consent and scope review matter more here, not less. Microsoft's own Sites.Selected permission (which now supports application mode) is worth knowing about specifically because it lets you restrict an application's access to specific sites/document libraries rather than granting organization-wide reach — a meaningfully safer middle ground for a ServiceNow integration that only needs to write to one specific document location.

6. Summary and Recommendation

If you're already using the delegated model:

• Use the Entra ID admin account only for configuring the OAuth application.
• Use a specific, intentionally-chosen runtime account to generate the OAuth token ServiceNow will hold — and treat "which account last authenticated" as a piece of configuration worth documenting explicitly, not something to leave implicit.

If predictable, admin-controlled file destination matters more than initial setup simplicity — which is true for most enterprise document-management use cases — application permissions, scoped down with Sites.Selected where possible, avoids the two-identity confusion entirely rather than just managing around it.

Both models are valid Microsoft Graph architectures. The choice isn't "which is correct" — it's which tradeoff fits your integration: delegated is simpler to reason about for a single user's personal files, while application permissions trade broader scope for eliminating the exact session-dependent ambiguity that causes the most common support confusion described above.