TL;DR: Applications can fetch Notion pages with a refreshed access token while WorkOS Pipes handles OAuth flow, token storage, and refresh logic, reducing the integration burden for B2B apps that need user context from Notion without building credential plumbing themselves, according to WorkOS. The identity lesson is that delegation convenience does not remove governance responsibility.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: WorkOS Pipes lets applications retrieve Notion pages with refreshed access tokens instead of building their own OAuth plumbing.
Why it matters: It matters because delegated app access still creates identity governance obligations around token scope, refresh behaviour, and revocation for NHI and SaaS-to-SaaS integrations.
Context
The core issue is not page retrieval itself, but how an application governs delegated access to a third-party workspace. OAuth removes password sharing, but it replaces that problem with token issuance, storage, refresh, revocation, and scope governance across the connected-account lifecycle.
For B2B applications, that lifecycle often sits in the NHI layer because the application uses machine-held tokens to act on a user's behalf. The control question is whether the integration keeps access bounded to the intended data, preserves offboarding when a connection is revoked, and avoids turning convenience into standing privilege.
Notion makes the example concrete because page access is granted at the page level, not the workspace level. That means the app may have a valid token and still have incomplete visibility, which is normal behaviour that teams need to design for rather than treat as an access failure.
Key questions
Q: What breaks when teams treat delegated SaaS access like a normal API key?
A: They lose the lifecycle controls that make delegated access safe. A connected SaaS token can be refreshed, revoked, or narrowed by the provider and the user's sharing choices, so treating it like a static secret hides important governance events and makes access review, offboarding, and troubleshooting much harder.
Q: When should organisations reauthorise external service connections?
A: Organisations should reauthorise external service connections when the business purpose changes, the user’s role changes, the connected provider changes scope requirements, or the integration has been idle for an extended period. Reauthorisation is the point where governance can confirm that the access still matches the current need. Without it, delegated credentials can persist well beyond their intended use.
Q: What are the signs that a connected workspace integration is too broad?
A: A broad integration usually shows up as more data than the user expected, weak explanations of why pages are visible, and support tickets about missing or unexpectedly visible content. Another signal is when product teams cannot clearly describe which pages, databases, or capabilities the app actually depends on.
Q: How should IAM teams govern page-level access in SaaS integrations?
A: They should map the actual authorization boundary first, then align product behaviour, logging, and support flows to that boundary. For Notion-like systems, that means distinguishing integration capability, user-selected sharing, and the token that lets the app call the API so reviews reflect the true access path.
Technical breakdown
OAuth delegation for SaaS-to-SaaS access
The pattern here is delegated authorization, where an application receives an access token that represents a user's consented access to a third-party API. In practice, the application does not own the resource owner session or the provider's login flow. It relies on OAuth 2.0 token exchange and refresh mechanics to keep the connection usable without re-prompting the user each time. That is why token handling becomes an identity control surface rather than a pure developer convenience. Once the app depends on a bearer token, the security model shifts from authentication of the user to governance of the token lifecycle, including expiry, refresh, scope, and revocation.
Practical implication: treat each connected SaaS account as a governed delegated identity, not as a simple API integration.
Why refreshed access tokens reduce plumbing but not trust
A refreshed access token reduces operational friction because the backend can request a usable token when needed instead of storing long-lived secrets or reimplementing redirect handling. But refreshability also introduces trust assumptions: the system that holds the refresh relationship can keep restoring access until the connection is explicitly revoked or becomes invalid. In Notion's model, the integration only sees pages the user chose to share, so authorization is both token-based and content-bound. That is materially different from broad workspace read access and it changes what the application should expect from the API response. Empty results may reflect user choice, not failure.
Practical implication: design UI and error handling to distinguish revoked access, missing sharing, and ordinary page-level permission limits.
Notion page-level permissions and consent boundaries
Notion does not expose all workspace content to every connected app. The user selects which pages and databases to share, and capabilities are configured on the integration itself in the Notion developer portal. That means the token alone is not the whole control story. Access is the combination of integration capability, user consent, and the specific pages shared into the integration. For identity teams, that is a classic example of entitlement granularity mattering more than connectivity. If product teams assume a connected workspace equals full visibility, they will misread the authorization model and build the wrong fallback logic.
Practical implication: map the integration's effective access path before designing data display, sync, or comment-write workflows.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegated app access is an NHI governance problem, not just an integration pattern. WorkOS Pipes changes who implements OAuth mechanics, but it does not change the fact that a machine-held token is now acting on behalf of a user. That places the integration squarely in NHI governance because the meaningful control questions are issuance, refresh, scope, and revocation. The practitioner conclusion is simple: if a connected SaaS app can read user data, it needs the same lifecycle accountability as any other non-human credential path.
Capability scope is the real boundary, and Notion makes that boundary visible. Notion permissions are set on the integration and constrained by what the user shares at the page level. This is more precise than many teams assume, and it matters because broad entitlement assumptions will overstate what the app can actually see. The practitioner conclusion is to govern to effective access, not to marketing-level descriptions of a connection.
Ephemeral token convenience does not eliminate standing-access risk. The token may be refreshed behind the scenes, but the underlying connection persists until someone revokes it or the user disconnects it. That means offboarding and reauthorization remain core controls, even when the developer experience feels abstracted away. The practitioner conclusion is to treat refreshable access as a managed privilege, not a permanent entitlement.
Temporary token use still leaves an accountability trail that IAM teams must own. When an app can fetch fresh access tokens on demand, the control problem moves from passwords to connection governance, logging, and reapproval triggers. That affects both human identity programmes and NHI oversight because the user consented to the connection, but the application operationalizes it as a non-human access path. The practitioner conclusion is to align application telemetry with identity governance workflows so revocation, review, and reauthorization are observable.
Notion access should be governed as a permissioned data pipe, not a generic API call. The important design distinction is that the app is not just calling an endpoint, it is inheriting a user-scoped authorization context with page-level limits. That means least privilege has to be interpreted in terms of shared pages, integration capabilities, and token lifecycle, not in terms of whether the OAuth dance was outsourced. The practitioner conclusion is to assess each connected service by the data it can actually reach, not by the ease of connection setup.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Delegated access needs the same governance discipline as any other non-human credential path. When an application can refresh tokens on behalf of a user, the security boundary moves from authentication to entitlement control, revocation, and auditability. Teams that still treat these integrations as simple app features will underbuild the lifecycle controls that make them safe.
Page-level consent is a useful reminder that integration success does not equal full visibility. Product teams should expect partial data, explicit sharing, and user-driven scope boundaries in systems like Notion. The operational implication is that exception handling and user messaging matter as much as the API call itself.
For practitioners
- Define delegated SaaS access as an NHI lifecycle Inventory every connected workspace token as a managed non-human credential, with ownership, renewal logic, and revocation responsibility assigned to a team.
- Separate integration capability from user sharing Document what the provider integration can do in its developer portal and what the end user actually shared at the page or database level.
- Handle revoked connections as a governance event Route getAccessToken failures, expired grants, and disconnected workspaces into a reauthorization path that is visible to support and security teams.
- Design for partial visibility by default Assume the API response may reflect only a subset of pages the user shared, and surface that limitation clearly in the product UI.
- Log token use separately from user sign-in Record which connected service, user, and organization requested each refreshed token so reviews can distinguish human login from delegated access.
Key takeaways
- Delegated access through refreshed tokens shifts risk from password handling to lifecycle governance over connected SaaS identities.
- Notion-style sharing is bounded by integration capability and user-selected pages, so valid tokens do not guarantee broad visibility.
- Teams should govern connected accounts as managed non-human identities, with explicit revocation, logging, and reauthorisation paths.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The integration depends on a third-party delegated identity and token handling path. |
| NHI-07 — Long-Lived Secrets | Refreshable access introduces persistence concerns even when the app does not store tokens directly. | |
| Recommendation — Review third-party delegated access paths under NHI-03 and verify ownership, scope, and revocation. Eliminate unnecessary token persistence and align refresh behaviour to NHI-07 lifecycle controls. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on token issuance, refresh, and revocation as authenticator lifecycle controls. |
| Recommendation — Apply IA-5 to govern issuance, renewal, and revocation of delegated access tokens. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Bearer tokens are the access mechanism that governs API reach in this integration pattern. |
| Recommendation — Map token misuse and exposure risks to TA0006 and monitor delegated access paths accordingly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about entitlement boundaries for connected SaaS accounts. |
| Recommendation — Align connected-account reviews to PR.AA-05 and verify the effective permissions behind each integration. | ||
Key terms
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Page-level Consent: Page-level consent is a sharing model where a user grants an integration access only to specific documents or databases rather than an entire workspace. In identity terms, it narrows blast radius, but it also requires product teams to communicate partial visibility clearly so missing data is not mistaken for failure.
- Connected Account: A third-party account that a user has linked to an application so the app can call an external provider on their behalf. In practice, the connection becomes a governed entitlement because it can persist, expand in scope, or remain active long after the original user action occurred.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org