WorkOS Pipes shifts OAuth plumbing out of app identity

At a glance

What this is: This is a tutorial on using WorkOS Pipes to let an app connect Linear and fetch issue data without implementing OAuth itself, shifting token handling and refresh responsibility into WorkOS.

Why it matters: IAM and platform teams should care because moving OAuth plumbing out of the app changes where credentials live, who can revoke them, and how connected SaaS access is governed across the integration lifecycle.

Context

OAuth integrations are more than a redirect and a token exchange. They create a lifecycle problem for the application owner: who stores credentials, who refreshes them, and who decides when a connected SaaS account should be cut off.

In this pattern, the app delegates OAuth flow handling and token refresh to WorkOS Pipes while continuing to call the upstream API with a usable access token. For identity teams, that shifts the governance boundary from application code to the delegated integration layer.

The article is about SaaS-to-SaaS access to Linear, but the broader issue is familiar across app identity programmes: once a third party mediates credential handling, operational control and accountability need to be explicit rather than assumed.

Key questions

Q: How should security teams govern third-party OAuth access for SaaS integrations?

A: Treat third-party OAuth grants as NHI assets with owners, scopes, and lifecycle rules. Require approval for high-risk permissions, inventory refresh-token use, and define revocation triggers for staff changes, app changes, and anomalous activity. The goal is to make delegated access visible enough to review and fast enough to remove.

Q: Why do mediated OAuth flows change the security model for connected apps?

A: Because the application no longer controls the entire credential lifecycle. A mediator can simplify implementation, but it also becomes part of the trust boundary for access persistence, scope changes, and token validity, so security review has to move from code paths to lifecycle control and evidence.

Q: What breaks when token refresh and storage are outsourced?

A: What breaks is direct visibility into how long access persists and who can revoke it. If the application cannot observe refresh events, consent changes, or account disconnects, then stale access can outlive the business relationship that created it.

Q: How do security teams compare managed OAuth plumbing with building it themselves?

A: Managed OAuth reduces application complexity, but it also concentrates control in a delegated platform. Teams should compare the two options by asking where revocation happens, how audit evidence is produced, and whether the chosen model supports lifecycle governance across all connected SaaS accounts.

Technical breakdown

Delegated OAuth plumbing changes the trust boundary

In a traditional OAuth integration, the application owns the redirect flow, token exchange, refresh handling, and storage of long-lived credentials. Pipes moves those responsibilities into a mediated layer, so the app requests a valid token when it needs one instead of managing the full lifecycle itself. That reduces code in the app, but it also means the app no longer directly controls the credential state that authorises API access. The effective trust boundary is now split between the app, WorkOS, and the downstream SaaS provider, which changes how access, revocation, and failure handling must be reasoned about.

Practical implication: Map the delegated token path end to end before allowing production use.

Access token retrieval is not the same as identity governance

The tutorial shows a backend call that returns an access token for Linear, but token retrieval alone does not answer who approved the connection, what scopes were granted, or how offboarding is handled. In governance terms, this is a machine-mediated authorization relationship, not a simple API call. The important distinction is that the application can consume the token without ever seeing the full OAuth machinery, which makes operational simplicity higher but can hide where lifecycle controls actually live. Identity teams need visibility into the source, scope, expiry, and revocation path of the delegated credential.

Practical implication: Treat token issuance as a governed lifecycle event, not a developer convenience.

Managed refresh logic reduces code, not risk ownership

Pipes refreshes tokens in the background so the application receives a usable token when it needs to call Linear. That removes refresh logic from the app, but it does not remove the need to govern stale access, connected account changes, or authorization drift. The security model now depends on the delegated platform behaving predictably when consent changes, scopes expand, or a user disconnects an account. For IAM and SaaS governance, the key question is whether the mediated layer exposes enough evidence to support review, revocation, and audit across the integration lifecycle.

Practical implication: Require audit visibility into refresh, scope change, and disconnect events.

Threat narrative

Attacker objective: Obtain or preserve usable API access to connected SaaS data through the delegated OAuth path.

1. Entry occurs when a connected SaaS account is authorised through a mediated OAuth flow and the application relies on the returned token rather than managing the full process itself.
2. Credential handling shifts into the delegated layer, where token storage and refresh become the control point for continued access to the downstream API.
3. Impact occurs if revocation, scope changes, or account disconnects are not surfaced clearly enough for the application owner to stop unintended access.
4. The end objective is sustained API access to third-party SaaS data through a valid token path that the application treats as ready to use.

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

OAuth delegation turns application identity into a governed supply chain: once a platform mediates redirects, token exchange, and refresh, the application no longer owns the full access path. That does not eliminate risk, it redistributes it across the app, the mediator, and the downstream SaaS. The governance question becomes whether the delegated layer exposes enough state for review, revocation, and audit. Practitioners should treat mediated OAuth as an identity supply chain, not just a developer convenience.

Token lifecycle ownership matters more than token retrieval convenience: the article’s core design removes refresh logic from the app, but refresh logic is exactly where stale access and revocation drift tend to hide. If the application cannot see when tokens were refreshed, what scope changed, or whether a user disconnected an account, then operational simplicity has obscured accountability. The practical implication is that lifecycle evidence must remain visible even when lifecycle execution is outsourced.

Managed credentials do not remove the need for trust boundary design: the app still depends on a valid access token, and that token still authorises real SaaS data access. The boundary has moved, not disappeared. This is where programmes that treat OAuth as a pure implementation detail fail, because identity governance for connected apps is fundamentally about who can create, sustain, and end delegated access.

Third-party app connections need offboarding logic, not just onboarding flow: the hardest part of SaaS-to-SaaS access is often not the first connection but the disconnect, reauthorisation, and scope change events that happen later. When those events are handled outside the app, ownership becomes ambiguous unless the organisation has explicit governance over the mediated integration layer. Teams should evaluate connected-app control as a lifecycle problem, not a feature toggle.

WorkOS Pipes shifts OAuth plumbing out of the app, but not out of the risk model: the risk moves from application code to delegated access governance. That means platform teams must still answer who approves the connection, who can revoke it, and how evidence is retained for audit and incident response. Practitioners should reframe the problem as delegated access governance across SaaS integrations.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Delegated access governance: SaaS integrations increasingly move credential handling out of application code and into intermediary platforms, which means security teams must govern the lifecycle of connected access rather than just the implementation pattern. The key question is whether the mediator exposes enough state for audit, revocation, and offboarding.

OAuth simplification often hides the control plane that identity teams actually need to manage. When token refresh, storage, and reauthorization are abstracted away, the programme still owns the risk if connected accounts retain access after scope or ownership changes.

For practitioners

• Define the delegated trust boundary Document which party owns redirect handling, token storage, refresh, revocation, and audit evidence before adopting mediated OAuth for production integrations.
• Inventory connected SaaS accounts Track every external account connection by user, organisation, provider, scope, and expiry so governance teams can review what the app can actually access.
• Require disconnect and reauthorisation workflows Make account disconnects, consent changes, and scope updates visible to both the application owner and the identity team so stale access does not persist unnoticed.
• Separate implementation simplicity from control ownership Treat background token refresh as an operational convenience, but keep approval, offboarding, and evidence retention under explicit governance controls.

Key takeaways

• OAuth delegation can reduce engineering effort while leaving the application responsible for the governance consequences of connected SaaS access.
• The control problem shifts from redirect code and refresh logic to trust boundary definition, revocation visibility, and offboarding evidence.
• Identity teams should treat mediated OAuth as a lifecycle issue, because the hard part is proving access can be reviewed and ended cleanly.

Key terms

• Delegated OAuth: A permission model that lets a user grant an application access to data without sharing a password. In identity governance terms, it shifts risk from credential theft to consent abuse, so the app registration, user role, and authorisation scope all need ongoing review.
• API Token Lifecycle: API token lifecycle is the full journey of a token from creation to retirement. It covers issuance, storage, use, rotation, renewal, revocation, expiration, and audit logging. In identity security, lifecycle control limits exposure, reduces replay risk, and ensures tokens remain tied to approved services, scopes, and time bounds.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Connected Account Governance: The controls that track, review, and remove third-party accounts linked to an application. It covers who can connect, what scopes are granted, how refresh is handled, and how access is ended when a user, vendor, or business relationship changes.

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.