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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Fetch GitHub repo data without OAuth using WorkOS Pipes”.
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.
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.
Q: How should teams govern token refresh for connected apps?
A: Define refresh ownership, expiry handling, and failure states before launch.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: Connected app access is increasingly being brokered by middleware, which changes where OAuth and token governance must live.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
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.
👉 Read our full editorial: OAuth plumbing for connected app data is shifting to middleware