OAuth plumbing for Google Drive access shifts to a brokered model

At a glance

What this is: This tutorial shows how to connect Google Drive in an app through WorkOS Pipes, with the key finding that OAuth flow handling, token storage, and refresh logic are brokered outside the application.

Why it matters: IAM practitioners should care because brokered third-party access changes where trust, lifecycle, and revocation controls live across NHI, human, and agentic workflows.

👉 Read WorkOS's tutorial on connecting Google Drive without OAuth plumbing

Context

OAuth is the trust layer that sits between an application and a third-party service, but in practice it creates a lot of identity work around token handling, refresh logic, and scoped access. In this pattern, the application no longer owns those mechanics directly, which reduces implementation burden but shifts governance attention to the brokered identity path and the controls around it.

For IAM teams, this is really a non-human identity and third-party access governance problem, not just an integration convenience problem. When a platform mediates access to Google Drive, the security question becomes who can connect, who can refresh, who can revoke, and how those decisions are audited across the full lifecycle.

Key questions

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. Define an owner for the connection, record the requested scopes, monitor token refresh and reauthorization events, and make revocation part of offboarding. The broker should sit inside access review and audit processes, not outside them.

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. Even if token handling is outsourced, the trust boundary remains real, scope creep can still happen, and account connections can outlive the business need. Governance has to cover connection lifecycle, not just code.

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. That creates shadow third-party access, weak auditability, and delayed offboarding when users leave or services change.

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.

Technical breakdown

Brokered OAuth flow and token lifecycle

WorkOS Pipes acts as the intermediary between the application, the user, and the upstream provider. The application renders a widget, WorkOS handles the OAuth handshake, and the backend requests an access token when it needs to call the provider API. That changes the control plane: your app no longer stores refresh tokens or implements redirect logic, but it still depends on token scope, expiration, and reauthorization events to keep the integration functional. The result is a cleaner application design, but also a stronger dependency on the broker's identity lifecycle handling.

Practical implication: treat the broker as part of your identity perimeter and review who can create, refresh, and revoke connected accounts.

Managed secrets, CORS, and widget trust boundaries

The tutorial shows that the integration still depends on API keys, client IDs, allowed web origins, and managed secrets in the application environment. Those are not just implementation details, they are identity and access controls for the integration surface. CORS configuration determines which origins can interact with the widget, while backend secrets determine who can ask WorkOS for tokens. In other words, the user connection flow is simplified, but the surrounding control boundary still has to be designed carefully.

Practical implication: inventory every secret, origin, and backend token path used by the widget before moving the pattern into production.

Provider scopes and delegated access to Google Drive

The example uses Google Drive scopes to define what the connected account can do, then calls the provider API with a fresh access token. This is delegated access, not direct authentication, so the scope boundary matters more than the UI surface. If the scope is too broad, the integration creates avoidable exposure. If the scope is too narrow, users cannot complete the workflow. The governance challenge is aligning requested scopes with actual application behaviour and ensuring the downstream API calls never exceed that intent.

Practical implication: map each requested scope to a concrete business function and remove any scope that is not required for the workflow.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Third-party account connections are NHI governance in disguise. A connected Google Drive account behaves like a non-human access relationship even when the end user is human. The operational question is not whether the app can fetch files, but whether the connected entitlement can be discovered, monitored, and removed when the relationship changes. This is where many teams still separate application integration from identity governance, and that separation leaves a blind spot.

Ephemeral access does not equal low-risk access. Even when the backend only asks for a token when needed, the trust decision remains durable if the account connection persists across sessions and users. The security issue is not just token freshness, it is the standing relationship between the application, the broker, and the upstream provider. Practitioners should recognise that delegated access can still create persistent exposure if the lifecycle is not governed.

Google Drive integration is becoming an identity orchestration problem, not a coding problem. The more applications rely on brokered access to external services, the more governance moves from individual code paths into central policy, audit, and revocation logic. That shift affects human workflows, NHI oversight, and eventually autonomous agents that consume the same brokered tokens. Teams should prepare for a broader access model, not just a simpler SDK.

From our research:

• 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.
• The visibility problem is the real signal to watch, so compare delegated-access inventory against our State of Non-Human Identity Security before scaling more brokered integrations.

What this signals

Delegated access will keep expanding faster than manual governance can track. As more apps outsource token handling and refresh logic, the control challenge shifts to inventory, lifecycle, and revocation. Teams should expect brokered third-party access to become a default pattern, which means identity governance must see connected accounts the same way it sees service accounts and API credentials.

Connection ownership will become the weak point if it is not assigned explicitly. When a third-party integration is easy to create, it is often harder to retire. The practical lesson is to make every connected account discoverable in review and offboarding workflows, because the lifecycle gap is where hidden access accumulates.

Third-party access visibility remains the scaling constraint. Our research shows 85% of organisations still lack full visibility into OAuth-connected vendors, which means most environments are not ready to govern this pattern at volume. Teams should use that gap as a trigger to tighten inventory and review controls before expanding integrations further.

For practitioners

• 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.
• Protect the widget and backend token path Restrict allowed web origins, store API keys as managed secrets, and monitor every backend call that requests a fresh access token from the broker.

Key takeaways

• Brokered OAuth simplifies application development, but it also moves identity governance into the integration layer.
• Delegated third-party access still creates persistent lifecycle risk if connected accounts, scopes, and ownership are not tracked.
• Visibility into OAuth-connected relationships is the deciding control, because what teams cannot inventory they cannot revoke or review.

Key terms

• Brokered OAuth: A delegated access model where a third party handles the OAuth flow, token storage, or refresh logic for an application. The app relies on the broker to obtain usable tokens, which reduces implementation burden but creates a separate governance boundary that still needs inventory, review, and revocation.
• Delegated Access Relationship: A persistent identity relationship in which one system acts on another system's behalf through granted scopes. It is more than a token exchange, because the connection can survive across sessions and business changes, so the lifecycle of the relationship must be governed like any other access grant.
• Managed Secret: A credential stored and handled through a controlled process rather than embedded in code or exposed to developers broadly. In this pattern, API keys and client IDs still need protection because they can be used to request tokens or interact with the broker on behalf of the application.
• Connected Account Lifecycle: The full lifecycle of a third-party account connection from creation through scope change, refresh, review, and revocation. For NHI governance, this lifecycle matters because access often persists even after the original business need changes, creating hidden exposure if offboarding is incomplete.

Deepen your knowledge

OAuth-brokered third-party access is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising governance for connected accounts and delegated tokens, it is worth exploring.

This post draws on content published by WorkOS: Integrate Google Drive in your app without OAuth using WorkOS Pipes. Read the original.