TL;DR: A pattern for connecting GitHub and other third-party services without building OAuth redirects, token storage, or refresh logic in the app, while still returning usable access tokens for API calls, is highlighted in WorkOS’s Pipes tutorial. That shifts the operational burden from application code to the integration layer, which changes how teams think about secret handling, delegated access, and account reauthorization.
At a glance
What this is: This tutorial explains how WorkOS Pipes lets applications fetch third-party data through a middleware layer that manages OAuth flow, credential storage, and token refresh on their behalf.
Why it matters: IAM and NHI teams should care because the control point for delegated access shifts from application code to the integration layer, changing how they govern tokens, scopes, and reauthorization.
Context
OAuth plumbing is the set of flows and storage patterns an application needs to connect to third-party services and keep those connections usable over time. In this pattern, the application no longer owns the redirect logic, refresh lifecycle, or token vaulting for the external service.
For identity teams, the governance question is not whether an app can call an API, but where delegated access is controlled and who owns reauthorization when the connection expires or is revoked. That matters across SaaS integrations, customer-facing apps, and any programme that treats third-party access as part of normal application design.
Key questions
Q: What breaks when OAuth tokens are not handled correctly in client applications?
A: Client applications can fail in several ways when token handling is weak. They may keep using expired tokens, misread revocation events, or expose stored tokens to interception and theft. That leads to failed requests, broken user access, and avoidable security exposure. Good implementations validate token state, store credentials securely, and recognize when a new token must be requested.
Q: Why does delegated third-party access increase IAM complexity?
A: Because the access is no longer just a login event, it becomes an ongoing relationship between a user, a provider, and the application. Scopes, expiry, refresh, and reauthorization all become part of the identity lifecycle, which creates more places for drift and outage if ownership is unclear.
Q: How should teams govern token refresh for connected apps?
A: Define refresh ownership, expiry handling, and failure states before launch. The key is to ensure the application can detect when a token is no longer usable and route the user back through reauthorization instead of silently failing or reusing stale credentials.
Q: When should organisations review connected account access?
A: Review connected accounts whenever scopes change, a provider is added, a user leaves, or the application’s data-sharing model changes. Those are the points where delegated access can drift away from the original approval and where access should be revalidated or removed.
Technical breakdown
Middleware-managed OAuth flow
WorkOS Pipes shifts the OAuth exchange out of application code and into a middleware layer. The app renders a widget for user connection, while the middleware handles provider configuration, consent, token issuance, and refresh behind the scenes. The application then asks for a usable access token only when it needs to call the provider API. This changes the integration boundary: the app no longer needs to maintain redirect handlers, refresh logic, or token persistence as first-class code paths. That reduces local complexity, but it also concentrates trust in the middleware layer that now brokers the delegated connection.
Practical implication: Treat the middleware as part of your access boundary and review its token handling, lifecycle, and failure modes before production use.
Access tokens, refresh tokens, and widget tokens
The article distinguishes three token types that often get conflated. Widget tokens authorize use of the Pipes widget. Access tokens let the backend call the provider API. Refresh logic is what keeps those access tokens usable over time without repeated user intervention. The important operational point is that the app consumes the output of a managed token service rather than maintaining token state itself. That model simplifies implementation, but it also means token scope, expiry, and renewal policy are no longer embedded in the app’s own data model and must be governed at the integration layer.
Practical implication: Separate widget authorization from provider API access in your design and document which component owns expiry, renewal, and revocation decisions.
Third-party account access as delegated identity
Connected app access is not just API consumption. It is delegated identity, because a user’s third-party account is being trusted to grant scoped access into another application workflow. The article’s GitHub example shows that the app can request repository data once WorkOS returns a valid token, but the underlying trust relationship still depends on scopes, reauthorization, and account state. For IAM and NHI governance, that makes the connection itself an identity object with lifecycle events, not just a transport detail. If the account is revoked, scopes change, or the user needs to reconnect, the integration must fail safely and visibly.
Practical implication: Inventory connected third-party accounts as governed access relationships and define how reauthorization, scope drift, and disconnect events are handled.
Threat narrative
Attacker objective: The operational objective is to obtain usable third-party access for API calls while reducing the integration burden inside the application.
- Entry begins when a user connects a third-party account through the Pipes widget and authorises scoped access to an external provider.
- Credential handling is centralised in the middleware, which stores and refreshes the tokens needed to keep API calls working over time.
- Impact occurs when the application uses the returned token to retrieve provider data without implementing its own OAuth flow or refresh logic.
Breaches seen in the wild
- 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.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
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 access is becoming an integration-layer governance problem: when OAuth flow, token storage, and refresh logic move out of the application, identity teams must govern the middleware that now brokers access. That changes the control plane, not just the implementation detail. The practical conclusion is that application teams and IAM teams now share responsibility for one delegated access boundary.
Token lifecycle is the real control surface: this pattern does not remove OAuth risk, it relocates it into issuance, expiry, refresh, and revocation management. The app sees a usable token, but the security outcome still depends on whether scope, TTL, and reconnect handling are enforced consistently. Practitioners should treat token lifecycle as the durable control, not the initial connection event.
Third-party account access is an NHI-like relationship even when a human starts it: the connected account persists as a governed access object after the user clicks connect. That means offboarding, scope review, and reconnection handling cannot be treated as one-time onboarding tasks. The implication is that account access reviews must include delegated SaaS connections, not only internal users.
OAuth plumbing for connected app data is really about blast-radius reduction: centralising credential handling can limit the places where secrets are duplicated, but it also creates a single trust broker whose failure affects every downstream integration. That concentration makes middleware inventory, monitoring, and recovery planning part of identity governance. Practitioners should map which integrations depend on the same broker before they scale the pattern.
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 needs lifecycle governance, not just integration convenience: once the app no longer owns the OAuth redirect and refresh path, the control problem shifts to inventory, ownership, and revocation of connected accounts. Teams should expect more value from access reviews that include external SaaS connections than from treating them as simple technical dependencies.
Middleware concentration creates a new trust broker: centralising token handling can reduce application complexity, but it also concentrates failure and visibility requirements in one service. Identity programmes should map which products depend on the same broker so a disruption or policy change does not become a hidden outage across multiple integrations.
For practitioners
- Map delegated SaaS connections as governed identities Record each connected provider, the scopes granted, the owning application, and the business process that depends on the connection. Treat these as lifecycle-managed access relationships rather than one-off integration settings.
- Separate widget access from API access Define who can render the connection widget, who can request provider tokens, and where the resulting tokens are allowed to be used. Keep those controls distinct in architecture and incident response documentation.
- Set explicit reauthorization triggers Require reconnection when scopes expand, when a provider changes token state, or when the user’s account is disconnected or disabled. Build clear failure handling so the app does not silently continue on stale consent.
- Reduce token duplication across services Avoid copying provider tokens into multiple internal systems unless there is a documented business need and a defined revocation path. The fewer places a token lives, the easier it is to govern its lifetime.
Key takeaways
- Connected app access is increasingly being brokered by middleware, which changes where OAuth and token governance must live.
- The main governance risk is not the API call itself but the lifecycle of delegated access, including refresh, reauthorization, and revocation.
- Identity teams should inventory connected accounts as governed access relationships and define ownership before the pattern spreads across more integrations.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, 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 — Vulnerable Third-Party NHI | The article centres on delegated access to GitHub and other third-party services. |
| NHI-07 — Long-Lived Secrets | The pattern depends on tokens remaining usable across refresh cycles and reauthorization events. | |
| Recommendation — Inventory third-party connections and verify ownership, scopes, and revocation paths for each delegated account. Minimise long-lived token exposure and enforce expiry and renewal controls for connected accounts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance, refresh, and revocation are authenticator lifecycle problems. |
| Recommendation — Apply authenticator management controls to token issuance, renewal, and invalidation workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Scoped delegated access must be governed as an authorization problem. |
| Recommendation — Review entitlements and permissions for connected SaaS accounts as part of access governance. | ||
| NIST Zero Trust (SP 800-207) | 5.3 — Continuous Verification | Token usability and account state change over time, so access must be rechecked continuously. |
| Recommendation — Revalidate connected account trust continuously instead of assuming the initial consent remains valid. | ||
Key terms
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Token Refresh: Token refresh is the process of replacing an expiring access token with a new usable credential without re-prompting the user. It reduces friction, but it also creates lifecycle dependencies that must be monitored so expired, revoked, or orphaned access does not linger unnoticed.
- Authorization Broker: An authorization broker is the control point that mediates access between an application and an external provider on behalf of a user or workload. In this pattern, the broker becomes part of the trust boundary because it controls consent handling, token issuance, and the visibility of connected accounts.
- 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 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org