WorkOS Pipes shifts Notion access from OAuth plumbing to token use

At a glance

What this is: WorkOS Pipes abstracts Notion connectivity so apps can request usable access tokens and list shared pages without implementing OAuth themselves.

Why it matters: IAM teams still have to govern delegated access, token lifecycle, and page-level entitlement boundaries even when the OAuth flow is hidden behind a widget.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read WorkOS's tutorial on fetching Notion pages without building OAuth

Context

The core problem is delegated access to third-party data without pushing every integration team through the full OAuth lifecycle. In practice, that means the application still depends on valid tokens, scoped permissions, and timely refresh behaviour, even if the developer never writes the redirect flow themselves.

For IAM and NHI programmes, this is a governance story about who owns the token, who can revoke it, and how entitlement changes are reflected when users disconnect or reauthorise a workspace. Notion page-level sharing also means the application only sees what the user explicitly exposed, so access boundaries are narrower than a workspace-wide assumption would suggest.

Key questions

Q: How should security teams govern third-party access when OAuth is abstracted away by a broker?

A: They should treat the broker as part of the trust chain, not as a convenience layer outside governance. That means tracking ownership, revocation responsibility, token lifecycle events, and downstream dependencies in the same control inventory used for other delegated access paths. If the broker can refresh or invalidate access, it is already participating in identity governance.

Q: Why do page-level permissions matter for Notion-connected applications?

A: Because a successful connection does not imply full workspace visibility. Notion grants access only to the pages or databases the user selected and the integration is allowed to reach, so product teams must design for partial context and explain missing results clearly. Otherwise, support teams will misread entitlement boundaries as application defects.

Q: What breaks when token refresh and revocation are treated as background plumbing?

A: The application loses the ability to distinguish between a temporary expiry, a user-driven disconnect, and a provider-side reauthorization requirement. That creates poor user messaging, weak auditability, and blind spots in lifecycle management. Refresh behaviour is not just an implementation detail; it is evidence of whether delegated access is still valid.

Q: How do IAM teams know whether a delegated Notion connection is still valid?

A: They need telemetry for token issuance, refresh, disconnect, and reauthorization events tied to the user and integration record. If those signals are missing, the team cannot prove whether access is current, revoked, or merely dormant. Validity in delegated access is a lifecycle question, not just an API response.

Technical breakdown

How token brokering changes delegated access patterns

Pipes acts as a broker between the application and the upstream provider. The app requests a valid access token when it needs data, while the broker manages refresh and storage in the background. That removes a common integration burden, but it also centralises reliance on a middleware layer that now becomes part of the trust chain. From an identity perspective, the important detail is not that OAuth disappears. It is that the control point moves from application code into the delegation service, which now determines whether a token is still usable and whether reauthorization is required.

Practical implication: Map the broker into your third-party access inventory and treat it as a control dependency, not just a developer convenience.

Notion page-level sharing and entitlement boundaries

Notion does not expose the entire workspace by default. Access is granted at the page or database level, based on what the user selects during the connect flow and what the underlying integration is allowed to do. That means a successful connection is not the same thing as broad data access. The app only receives a token for the subset of content the user has shared, which can make results look incomplete if the UI assumes workspace-wide visibility. The operational issue is entitlement mismatch, not authentication failure.

Practical implication: Design UI and support flows around page-level visibility so users understand why some content is intentionally absent.

Why refresh handling still matters even when the app never stores refresh tokens

Hiding refresh logic does not remove lifecycle risk. The token still expires, can be revoked, and can become invalid if the user removes the integration or changes sharing. A secure integration therefore needs error handling that distinguishes expired access from disconnected access, because those are different remediation paths. This is especially relevant in automation-heavy products where downstream features silently depend on continued access to Notion content. If the app treats every token problem as a generic API failure, it obscures the governance state of the connection.

Practical implication: Build explicit reconnect and revocation handling so access failures surface as identity events, not generic service errors.

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

Delegation convenience has not removed token governance. WorkOS Pipes changes where OAuth complexity lives, but it does not change the underlying identity problem: a third-party token still exists, still authorises access, and still needs lifecycle control. The field should stop treating integration abstraction as governance abstraction. The practitioner implication is that token brokering services belong in the same control map as any other delegated access path.

Page-level consent is a narrower trust model than many B2B teams assume. Notion sharing is scoped to specific pages and databases, not the whole workspace. That is a useful limitation, but it also means product teams must design around partial visibility instead of assuming that a connected account equals full context. The implication is that entitlement design and UX messaging are now part of identity governance, not just product usability.

Secret storage is displaced, not eliminated. The tutorial removes refresh-token handling from the application, but there is still a live credential dependency somewhere in the chain. This is a classic control displacement pattern in NHI governance: the operational burden moves to a different layer, while the business risk remains if revocation, expiry, and scope changes are not handled cleanly. Practitioners should therefore evaluate the broker, the provider integration, and the downstream app as one identity surface.

Integration abstraction is becoming a standard pattern across SaaS access, which raises the governance bar. The named concept here is delegated token brokerage: a service that stands between an application and the upstream provider to manage access-token acquisition and refresh. That pattern reduces developer friction, but it also concentrates trust and makes visibility into lifecycle state more important. The implication is that IAM teams will need to govern the broker relationship, not just the embedded app integration.

Access failures need to be classified as entitlement events, not just application errors. When a user disconnects a workspace or a token is revoked, the application is really learning something about identity state. That state change should feed monitoring, support, and recertification processes, especially where user-driven sharing controls what the app can see. The implication is that access telemetry and identity telemetry must be joined if teams want to understand whether a connection is still valid and appropriately scoped.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• If delegated access is part of your app architecture, review the Guide to the Secret Sprawl Challenge for the lifecycle and exposure patterns that create persistent credential risk.

What this signals

Delegated token brokerage will become a standard pattern in enterprise app design, but the governance burden does not disappear when OAuth is hidden from developers. IAM teams should expect more products to externalise token handling into middleware, which means revocation, consent state, and access ownership need explicit control mapping before rollout.

The practical signal for programmes is that identity state is now distributed across the app, the broker, and the upstream SaaS provider. If those signals are not joined, access reviews will miss revoked or dormant connections and the organisation will confuse integration uptime with legitimate access.

The risk surface is also widening beyond traditional secret storage. Our research shows that 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, which is a reminder that lifecycle governance has to follow the credential wherever it appears, not just where the application stores it.

For practitioners

• Inventory delegated token brokers as identity control points Record every integration where the application requests a usable access token from an intermediary service. Document who owns revocation, who receives disconnect events, and which downstream features depend on the token remaining valid.
• Design for page-level consent, not workspace assumptions Update onboarding, help text, and support flows so users understand that shared content is limited to the pages or databases they explicitly selected. Expose a clear path for expanding sharing when results look incomplete.
• Classify refresh and revocation failures separately Treat expired access, removed consent, and provider-side reauthorization as different conditions in logs and alerts. That distinction is necessary for incident triage, user messaging, and lifecycle tracking.
• Join access telemetry to identity lifecycle signals Correlate token issuance, refresh, disconnect, and reauthorization events with the user record so you can prove whether the connection is still active and legitimate. Use the same telemetry to drive recertification and support workflows.

Key takeaways

• WorkOS Pipes reduces OAuth implementation effort, but it does not remove the need to govern delegated access, token lifecycle, or revocation responsibility.
• Notion sharing is page-scoped, so a connected workspace can still expose only partial context and create entitlement misunderstandings if the UI is not explicit.
• The control question is no longer whether an app can fetch a token, but whether the organisation can prove that the token is still valid, appropriately scoped, and revocable.

Key terms

• Delegated Token Brokerage: A delegated token broker is an intermediary service that acquires, stores, refreshes, or invalidates access tokens on behalf of an application. It reduces integration overhead, but it also becomes part of the identity trust chain and must be governed like any other access control dependency.
• 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.
• Token Lifecycle: Token lifecycle is the full sequence of issuing, refreshing, expiring, revoking, and reauthorizing a credential. For delegated access, lifecycle state is the real indicator of whether a connection is still legitimate, because a valid-looking token can still be stale, disconnected, or out of scope.
• Consent Boundary: A consent boundary is the limit of what a user explicitly allowed an integration to access. It is defined by the provider's permissions model and the user's selections, not by the application's wish for broader context, which makes it central to governance and user trust.

Deepen your knowledge

Delegated token brokerage and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing app integrations that hide OAuth complexity from developers, the course is a useful fit.

This post draws on content published by WorkOS: Fetch Notion pages without OAuth using WorkOS Pipes. Read the original.