TL;DR: A flaw in Microsoft’s OneDrive File Picker can let connected web apps access a user’s entire OneDrive instead of only selected files, affecting hundreds of apps and potentially millions of users, according to Oasis Security. The issue exposes how vague consent, broad OAuth scopes, and token handling can turn routine file sharing into enterprise data exposure.
At a glance
What this is: Oasis Security found that OneDrive File Picker can grant web apps read access to an entire OneDrive, not just the files users intended to share.
Why it matters: IAM, IGA, and security teams need to treat delegated app access as a governance problem because overly broad OAuth consent can create silent data exposure across human and non-human identities.
👉 Read Oasis Security's analysis of the OneDrive File Picker scope flaw
Context
OneDrive File Picker is supposed to support a narrow user action, but the flaw described by Oasis Security turns that narrow consent flow into broad delegated access. For IAM teams, the core problem is not file upload convenience, it is that OAuth consent, token storage, and delegated permissions can quietly exceed the user’s intent.
That creates an identity governance issue across both human access and non-human application access. When a web app receives broader access than the task requires, the resulting blast radius is governed by token scope, refresh behavior, and application hygiene rather than by the user’s original decision. This is why delegated access reviews and consent controls belong in the same programme conversation as NHI governance.
Key questions
Q: What breaks when OneDrive integrations request broader access than the user action requires?
A: The access model stops matching user intent. A file picker that asks for full-drive read permission can turn a single upload into tenant-wide exposure if the app stores tokens or keeps a refresh token. The failure is not just over-permissioning. It is a broken boundary between consent, scope, and the actual data needed for the task.
Q: Why do delegated web apps create governance risk for IAM teams?
A: Delegated web apps inherit access from the user but operate with their own token lifecycle, which makes them harder to review than direct human sessions. If scopes are broad and tokens persist in the browser, the app can continue acting after the user believes access has ended. That is a governance problem, not only a technical integration detail.
Q: How do security teams know whether a file picker integration is too permissive?
A: Look for a mismatch between the user-facing task and the scopes requested. If a simple file upload requires full-drive access, the integration is too permissive unless there is a documented technical reason and compensating control. Also check whether refresh tokens exist, because they extend the effective access window beyond the visible session.
Q: Should organisations allow browser-based storage of access tokens for SaaS integrations?
A: No, not without a very strong justification and compensating controls. Browser storage increases the chance of token exposure through application context, extensions, or misconfiguration, and it weakens revocation discipline. For high-value collaboration tools, teams should prefer secure token handling, short-lived access, and explicit disposal when the task is complete.
Technical breakdown
Why the OneDrive File Picker scope model is too broad
The flaw exists because the file picker implementation requests read access to the full drive, even when the user expects to upload a single file. In practice, that means the permission boundary is set by the integration pattern rather than the user’s specific intent. Where OAuth lacks fine-grained scopes, consent prompts become a weak proxy for authorisation, especially when the text shown to users does not clearly explain the breadth of access. The technical risk is not just over-permissioning, but a mismatch between interface intent and backend entitlement.
Practical implication: review delegated app consent flows where the requested scope is broader than the user-facing action.
How browser token handling increases exposure
The article notes that the newer implementation pushes authentication handling into the application, often through MSAL and an authorization flow. That matters because tokens stored in browser session storage or local storage are accessible to the application context and can persist longer than the user expects. If refresh tokens are issued, the access window extends well beyond the immediate upload session. In identity terms, the secret is not just granted, it is also kept in a place that can outlive the task that justified it.
Practical implication: treat client-side token persistence as an access governance issue, not only a coding choice.
Why delegated access can outlive the original user action
This pattern combines consent, token issuance, and app logic into a single ongoing trust relationship. Once a refresh token exists, the app may continue accessing the account even after the user thinks access has stopped. That creates a lifecycle problem for delegated identities because revocation intent and technical expiry are not the same thing. The control failure is temporal: access can continue after the human has moved on, especially if the app is not instrumented for token disposal and revalidation.
Practical implication: enforce revocation checks and token disposal requirements for delegated web apps that touch OneDrive.
Breaches seen in the wild
- Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Consent prompts are not a governance boundary when the requested scope exceeds the task. The OneDrive File Picker issue shows how easily user intent and application entitlement diverge when the platform has no fine-grained OAuth scope to express the real limit. That is an access design problem, not a user education problem. For identity teams, the implication is that delegated consent cannot be treated as proof of least privilege when the underlying protocol forces broad access.
Browser-stored tokens create a delegated identity lifecycle problem, not just a session problem. When access tokens and refresh tokens live in client-side storage, the app acquires a persistence model that is invisible to the user and often outside normal review cadences. This is where delegated access becomes a governance issue for both IAM and NHI programmes, because the secret is now the operational control point. Practitioners should recognise that session timeout alone does not restore accountability.
Ephemeral file sharing becomes long-lived data access when refresh tokens are in play. The security assumption that a user’s upload action is narrow and temporary fails once the app can keep renewing access. That assumption was designed for human-paced review and explicit task boundaries. It fails when the access mechanism is programmable, persistent, and decoupled from the user’s immediate intent. The implication is that teams must rethink how delegated apps are classified, reviewed, and revoked.
OneDrive integrations expose a named concept we should call consent-to-scope drift. The consent event says one thing, while the granted scope and token behavior do another. This drift is now a practical category of identity risk across SaaS integrations, because it turns seemingly bounded collaboration features into broad read access. For practitioners, the lesson is to evaluate the integration contract, not just the consent screen.
This flaw shows why NHI governance cannot stop at service accounts and API keys. Delegated application access is also a non-human identity problem because the app holds and uses secrets on behalf of a user. The access path may begin with human approval, but the operational risk sits with the tokenized application. Teams that only review human access miss a large class of effective privilege.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- This is why Ultimate Guide to NHIs , Key Challenges and Risks matters: secret sprawl and delayed revocation turn delegated access into a durable exposure path.
What this signals
Consent-to-scope drift is the right lens for this flaw: the user sees a narrow action, while the application receives wider delegated authority than the action requires. That gap is becoming a category-level governance issue for SaaS integrations that rely on browser-mediated OAuth flows, especially where token handling is pushed into application code. For practitioners, the operational question is no longer whether users consented, but whether the granted scope is actually defensible.
With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs, the OneDrive File Picker pattern fits a broader identity problem: secrets are often kept in the least governable place. That means access reviews must include delegated apps, browser token paths, and revocation mechanics, not just directory entitlements.
The next programme decision is whether to classify these integrations as collaboration convenience or as non-human identity risk. The answer matters because the same control logic used for NHI secrets applies here: scope minimisation, storage discipline, and explicit offboarding. Teams that separate SaaS integration hygiene from identity governance will keep missing the real blast radius.
For practitioners
- Audit OneDrive delegated app consent paths Inventory every app that uses OneDrive File Picker and compare the granted scopes with the actual upload or download function. Flag integrations where the permission request is broader than the task and require security review before continued use.
- Remove refresh-token persistence from browser-based flows Eliminate code paths that store access tokens or refresh tokens in session storage or local storage. Require secure disposal on logout, consent revocation, or application decommissioning, and verify that tokens are not left recoverable in the browser.
- Treat delegated app access as part of access review Include enterprise applications using OneDrive in periodic access certification, not just human user reviews. Confirm who granted the permission, what scope was approved, and whether the app still needs access to the tenant’s files.
- Use narrower file-sharing alternatives where possible Where business processes allow it, replace broad OAuth-based file picker flows with view-only links or another pattern that avoids handing a web app long-lived read access to the entire drive.
Key takeaways
- The flaw turns a narrow file-selection workflow into broad OneDrive read access, which is a scope and consent failure, not just a product bug.
- The exposure is amplified when apps store tokens in the browser or keep refresh tokens alive, because revocation intent and technical expiry do not align.
- Security teams should review delegated app scopes, browser token handling, and access certification together, because collaboration features now behave like governed identity pathways.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Broad delegated scopes and token persistence map to NHI credential risk. |
| NIST CSF 2.0 | PR.AC-4 | Delegated app access must be reviewed as part of access entitlement governance. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust demands continuous validation of delegated access and session boundaries. |
Minimise delegated scope and verify token storage against NHI-03 before approving integrations.
Key terms
- Delegated Access: Delegated access is permission that one application or service receives to act on behalf of a user or another identity. In identity governance terms, it must be reviewed like any other privileged relationship because the app can often retain access independently of the user’s visible session.
- Refresh Token: A refresh token is a credential that allows an application to obtain new access tokens without requiring the user to sign in again. It extends the life of delegated access and can become a hidden persistence mechanism if storage, disposal, or revocation are not tightly controlled.
- Consent-to-scope Drift: Consent-to-scope drift is the mismatch between what a user thinks they approved and the actual access an application receives. It often appears in integrations where the interface describes a narrow task, but the underlying OAuth scope or token behavior grants broader and longer-lived access.
- Token Persistence: Token persistence is the retention of access or refresh tokens beyond the immediate task that justified them. In browser-based integrations, it increases the chance of unauthorized reuse, complicates revocation, and creates a governance problem because the credential outlives the user’s intent.
Deepen your knowledge
OneDrive File Picker scope drift and delegated token handling are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to govern SaaS integrations that behave like non-human identities, it is a practical place to start.
This post draws on content published by Oasis Security: OneDrive File Picker flaw provides ChatGPT and other web apps full read access to users’ entire OneDrive. Read the original.
Published by the NHIMG editorial team on 2026-05-27.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org