Notifications
Clear all
Topic starter
07/06/2026 8:16 pm
TL;DR: Applications can connect Google Drive and other third-party services without implementing OAuth redirects, refresh handling, or local credential storage, while the backend requests usable access tokens on demand for API calls, according to WorkOS. That brokered model simplifies integration, but it also centralises trust and makes third-party access governance a first-class identity problem.
NHIMG editorial — based on content published by WorkOS: Integrate Google Drive in your app without OAuth using WorkOS Pipes
Questions worth separating out
Q: How should security teams govern third-party app connections that use brokered OAuth?
A: Treat each connected account as a governed identity relationship, not just a feature toggle.
Q: Why do brokered access patterns still need strong identity governance?
A: Because the application still relies on a persistent delegated relationship to a third-party service.
Q: What breaks when teams treat OAuth integration as a pure development task?
A: They usually lose visibility into who connected what, which scopes were granted, where tokens are refreshed, and how to revoke access cleanly.
Practitioner guidance
- Map connected accounts to governance owners Assign a business and technical owner for every third-party connection so revocation, scope changes, and reauthorization are not left to the application team alone.
- Classify brokered integrations as NHI relationships Track each connected provider account, token path, and scope set in identity governance tooling so the relationship is visible during access reviews and offboarding.
- Minimise scopes to the live workflow Document the exact Google Drive operations the app performs and remove any unused read, write, or delete scope before production rollout.
What's in the full article
WorkOS's full tutorial covers the implementation detail this post intentionally leaves for the source:
- Step-by-step setup of the Pipes widget for Google Drive connections and account management
- Backend code examples for fetching refreshed access tokens from WorkOS before API calls
- Production guidance for configuring OAuth credentials, allowed origins, and API keys
- Token and scope handling details for extending the same pattern to additional providers
👉 Read WorkOS's tutorial on connecting Google Drive without OAuth plumbing →
Google Drive without OAuth plumbing: what changes for IAM teams?
Explore further
07/06/2026 10:06 pm
Brokered OAuth shifts the burden of control, it does not remove it. The application no longer implements the redirect flow or stores refresh tokens, but it still depends on delegated access, scope discipline, and revocation handling. That makes the broker part of the identity governance stack, not an abstraction that sits outside it. Practitioners should treat token brokering as an IAM decision point with lifecycle consequences.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 38% have no or low visibility, and a further 47% have only partial visibility into those OAuth-connected vendors, which leaves a material governance gap.
A question worth separating out:
Q: How can IAM teams tell whether delegated access is becoming over-permissive?
A: Look for broad scopes that exceed the app's actual file or API needs, long-lived connections with no owner, and reauthorization requests that are disconnected from business events. Those are signs that delegated access is drifting beyond its intended boundary and should be tightened.
👉 Read our full editorial: OAuth plumbing for Google Drive access shifts to a brokered model
