ServiceNow + OneDrive OAuth Tokens: Why Files Keep Uploading to the Wrong User’s Folder

Many ServiceNow teams experience a confusing issue:

"We clicked Get OAuth Token, but files upload to the wrong user's OneDrive folder."

This happens even when logged in as a different ServiceNow user, or when impersonating. The root cause is not in ServiceNow at all — it's in Microsoft session handling. Let's explain the mechanics first, then cover the two ways to actually get past this permanently rather than managing around it every time.

1. OAuth Token Is Issued to the Active Microsoft Session

When you click Get OAuth Token in ServiceNow:

• ServiceNow triggers an OAuth flow.
• Microsoft checks who is currently signed in.
• Microsoft issues an OAuth token for that account.
• ServiceNow stores that token under the user record.

ServiceNow is simply the redirect channel here. Microsoft chooses the identity, based entirely on whatever browser session happens to be active at that moment.

2. VDI / SSO / Teams Auto-Login Makes This Worse

Many enterprise users log into a VDI or laptop using SSO, causing Microsoft apps like Teams, Outlook, Office.com, and the OneDrive client to automatically authenticate using a personal or admin account.

This means:

• Even if you open an Incognito window.
• Even if you log in to ServiceNow as a different user.
• Even if you impersonate.

Microsoft will still issue a token belonging to the cached session — none of the ServiceNow-side workarounds above touch Microsoft's own session state.

3. Why You Were Never Prompted for Microsoft Credentials

Because the browser already had a valid Microsoft authentication session via PingOne (if used), native Windows sign-in, Office apps auto-login, or a VDI identity provider. Microsoft never prompts again unless that session is explicitly cleared.

4. How to Generate a Token for the Correct OneDrive Account

You must ensure the Microsoft session belongs to the OneDrive service account.

Correct procedure:

1. Sign out from all Microsoft apps (Teams, Outlook, OneDrive sync client).
2. Clear browser cookies.
3. Open a clean incognito window.
4. Manually sign in to Microsoft using the OneDrive service account.
5. Log in to ServiceNow using the same account (real login, not impersonation).
6. Click Get OAuth Token.

Now the token will belong to the correct OneDrive account.

5. Why Impersonation Does Not Work

Impersonation changes only the ServiceNow identity. It does not — and cannot — change the Microsoft identity, browser sessions, SSO sessions, or Office login state. Impersonation is entirely a ServiceNow-side concept; Microsoft's authentication layer has no awareness of it whatsoever. Thus, impersonation cannot control where files get stored.

6. The Newer Alternative: The Official Microsoft OneDrive / SharePoint Online Spoke

Everything above describes how to correctly manage the delegated OAuth flow — but it's worth being direct about what it actually is: a manual, session-dependent process that has to be redone carefully every time the wrong Microsoft identity gets cached. If this keeps happening on your instance, it's worth considering ServiceNow's official Microsoft OneDrive Spoke and Microsoft SharePoint Online Spoke, available through Integration Hub, as a structural fix rather than a repeated manual procedure.

Here's what makes this genuinely different, not just more convenient: the SharePoint Online Spoke's standard setup uses a certificate-based application identity — an Azure app registration authenticating with a certificate rather than a delegated user session — with the option to scope access down to Sites.Selected instead of the broader Sites.FullControl.All. This is the application-permissions model, the same structural fix discussed in this blog's companion article on why ServiceNow needs two Microsoft identities. Because there's no signed-in user involved, there's no "whichever session happens to be cached" problem to manage at all — the identity is fixed at the application level, not determined by whoever's browser session is active when a token gets requested.

A few practical setup notes if you go this route:

• The Spoke uses a Connection & Credential Alias to store its authentication configuration — worth knowing that these records are not captured in Update Sets, so each environment (Dev, Test, Prod) needs its connection, credential, alias, and app registration configured fresh rather than promoted through the normal change pipeline. Static values like the OAuth app registry details can be stored in a system property and referenced across environments to reduce repeated manual entry.
• If you hit authentication errors during setup specifically, check Key Management > Module Access Policies — this module isn't always available to admins by default, and a missing or misconfigured target script entry (commonly surfaced as an OAuthUtilSPJWTOnline-related script) is a known, specific cause of setup-time authentication failures.
• Choose Sites.Selected over Sites.FullControl.All during setup wherever your integration only needs to reach specific document libraries — this keeps the Spoke's broader application-level reach appropriately scoped rather than granting organization-wide access by default.

Summary

ServiceNow does not decide where OneDrive files go — the Microsoft account active during OAuth does, if you're using the delegated flow described in Sections 1 through 5. To fix file uploads going to the wrong folder under that model:

• Ensure the correct Microsoft identity is active.
• Use clean browser isolation.
• Log in to ServiceNow with the OneDrive service account before generating the token.

Once properly configured, files will upload into the correct OneDrive or SharePoint folder — but if this is a recurring operational headache rather than a one-time setup issue, moving to the certificate-based Microsoft OneDrive or SharePoint Online Spoke removes the session-dependency at its root, rather than requiring the careful manual procedure above every time it resurfaces.