OAuth plumbing for connected app data is shifting to middleware

At a glance

What this is: This is a tutorial on using WorkOS Pipes to connect GitHub and fetch repository data without implementing OAuth in the application.

Why it matters: It matters because delegated third-party access is still identity work, and IAM teams need to understand where token custody, refresh, and reauthorization now sit across NHI, autonomous, and human workflows.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read WorkOS's tutorial on fetching GitHub repo data with Pipes

Context

OAuth delegation is still an identity problem even when the application itself never stores a refresh token. The primary issue is not just developer convenience, it is where trust, credential custody, and reauthorization authority move when a third-party service becomes part of the application’s data path.

For IAM and NHI programmes, this pattern is familiar: a user connects an external account, the platform brokers access, and the app consumes a usable token on demand. The governance question is whether that token flow is controlled as an identity lifecycle, not merely treated as an integration shortcut.

Key questions

Q: How should security teams govern brokered OAuth connections in SaaS apps?

A: Security teams should govern brokered OAuth connections as part of the identity estate, not as a developer convenience. That means tracking provider, scope, owner, refresh behaviour, and revoke paths for each connected account. The control objective is to keep delegated access visible, reviewable, and removable when the user, app, or provider relationship changes.

Q: Why do brokered access tokens still create identity risk?

A: Brokered access tokens still create identity risk because the application may not store the refresh logic, but the underlying connection can remain active for long periods. If scopes are too broad, reauthorization is unclear, or offboarding is missed, the token path becomes a persistent external trust relationship. That is an identity control problem, not just a technical one.

Q: What do teams get wrong about third-party account connections?

A: Teams often treat third-party account connections as temporary integrations rather than managed entitlements. In practice, those connections can outlive the feature, the user, or even the vendor relationship if nobody owns them. The common failure is assuming the platform layer has solved governance, when it has only abstracted the OAuth ceremony.

Q: How do organisations know brokered access is actually under control?

A: Organisations know brokered access is under control when every connected provider account has an owner, a defined scope, an auditable reauthorization path, and a documented revoke process. If security cannot answer who owns the connection or how it is retired, the control surface is incomplete and the risk is still active.

Technical breakdown

Brokered OAuth and token custody in connected apps

Brokered access means the application never directly owns the full OAuth ceremony. A middleware layer, in this case WorkOS Pipes, handles the authorization grant, stores credentials, refreshes tokens, and returns a usable access token when the app needs to call the provider API. That reduces implementation burden, but it also centralises trust in the broker’s token lifecycle. The app still depends on scope selection, reauthorization events, and expiry handling to remain safe and functional. In identity terms, this is delegated access with a managed custody boundary, not removal of identity governance.

Practical implication: treat the broker as part of your identity control plane and review where token storage, refresh, and expiry are actually governed.

Refresh tokens, access tokens, and reauthorization windows

The article distinguishes between the long-lived credentials that keep a connection alive and the short-lived access token used to call the provider API. The value of a brokered pattern is that the application asks for a valid token only when needed, while the platform handles refresh logic and can force the user back through reauthorization when the connection is no longer valid. That creates an operational boundary for third-party access, but only if expiry, missing scopes, and stale consent states are surfaced cleanly to the application and the user.

Practical implication: build explicit reauthorization handling into the user workflow so failed token retrieval becomes a controlled identity event, not a broken feature.

GitHub repo access as a non-human identity workflow

When a backend service calls GitHub on behalf of a user, the resulting access pattern behaves like a non-human identity flow even though a human initiated the connection. The workload consumes a token, invokes the provider API, and may repeat that action over time without additional human involvement. That is why these integrations need NHI-style control thinking: scope minimisation, connection tracking, token visibility, and offboarding logic when the underlying account or organisation changes. The app is no longer just authenticating a user, it is operating a delegated machine-to-machine trust path.

Practical implication: govern connected-service access as an NHI lifecycle, including entitlement review, offboarding, and scope drift checks.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Delegated third-party access is an identity lifecycle, not a coding convenience. This tutorial shows a brokered token model where the app asks for a usable access token only when needed, while the middleware owns refresh and storage. That is operationally cleaner, but it still creates an entitlement that must be tracked, reviewed, and offboarded like any other non-human access path. Practitioners should stop treating embedded integrations as outside IAM scope.

Ephemeral access does not eliminate standing trust in connected-app workflows. The application may not persist refresh logic, but the connection itself remains active until revoked or reauthorized. That means the risk moves from local credential handling into connection governance, scope visibility, and stale consent management. For identity teams, the important question is whether these brokered grants are visible anywhere in the lifecycle inventory.

GitHub repo retrieval through a brokered token flow is a workload identity pattern in disguise. The backend service is the actual runtime executor, even if a person initiated the connection. That makes scope control, token provenance, and offboarding discipline more important than the UI that collected consent. The practitioner conclusion is straightforward: if the workload can keep calling the provider, then the identity relationship has to be governed as workload access, not just user convenience.

Connection brokers are becoming the new control point for third-party identity sprawl. As more applications outsource OAuth plumbing, the governance burden shifts to whatever system is brokering credentials and refresh. That can improve consistency, but it also concentrates failure if organisations do not inventory which apps depend on brokered access. Practitioners should expect IAM reviews to expand from direct app registrations to brokered connection inventories.

Persistent external account links blur the line between user identity and non-human execution. The user authorizes the connection once, but the app continues to act later through a tokenized service path. This is where many governance models become too narrow, because they only review the human consent event and miss the downstream machine execution surface. The field needs to recognise this as delegated NHI behaviour with human-originated consent.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• In the same research, 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• For a broader control model, the Ultimate Guide to NHIs lays out lifecycle governance, visibility, rotation, and offboarding patterns that apply cleanly to brokered access flows.

What this signals

Delegated integration sprawl is becoming a lifecycle problem for IAM teams. As more application teams outsource OAuth handling to brokers, the number of connected accounts that need ownership, scope review, and revocation tracking grows quietly. The programme signal is not just more integrations, but more places where identity state can persist after the original business need has changed.

Connection ownership needs to move into the same review cycle as other non-human credentials. If a backend can still request tokens for a provider, then the connection is functionally alive even when the original feature or user context has drifted. Security teams should expect offboarding checks, access reviews, and service ownership records to expand into brokered application connections.

Workload delegation now sits at the intersection of IAM and NHI governance. The human user may initiate consent, but the backend workload performs the ongoing action path, so the lifecycle has two faces. That is why this pattern belongs in connected-account inventory, not just in application configuration management.

For practitioners

• Inventory brokered third-party connections Catalogue every application that outsources OAuth, token refresh, or secret storage to a middleware layer, and map each one to the provider, scope set, and owning business service. Include reauthorization triggers and revoke paths in the inventory so the connection is governed as part of the identity estate.
• Classify connected-service tokens as NHI credentials Treat access tokens used by backend jobs, integrations, and API calls as non-human identity assets rather than generic app data. Assign ownership, review cadence, and offboarding responsibility for each connected account so stale grants do not survive user or vendor changes.
• Enforce scope-minimised provider connections Define the minimum provider scopes needed for each use case, then reject broad grants that are not required for the feature. Recheck scope sets whenever the application expands to new data types or provider actions, because scope drift often appears after the initial integration is working.
• Build reauthorization and expiry handling into product flows Surface failed token retrieval, expired consent, and missing scopes as explicit user states rather than silent backend errors. That keeps delegated access observable and prevents broken connections from turning into hidden availability or security issues.

Key takeaways

• Brokered OAuth removes implementation burden, but it does not remove identity governance.
• The main risk is persistent delegated access that outlives the user, feature, or business need.
• Teams should inventory connected accounts, minimise scopes, and govern token lifecycle as NHI access.

Key terms

• Brokered OAuth: A delegated access pattern where a middleware service handles the OAuth ceremony, stores or refreshes credentials, and returns usable tokens to the application when needed. The app no longer owns the full login exchange, but it still depends on the broker’s control over consent, scope, expiry, and revocation.
• 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.
• Token Custody: The control responsibility for where access tokens and refresh logic live, who can retrieve them, and how they are retired. In delegated integrations, token custody is often moved out of the app, but security ownership does not disappear. It shifts to the broker and the governance model around it.
• Reauthorization: A fresh consent or credential-validation step required when a previously approved connection can no longer be trusted or used. For delegated application access, reauthorization is the moment when expired, missing, or changed scopes should surface as a managed identity event rather than a silent failure.

Deepen your knowledge

Connected third-party account flows and delegated token handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing application integrations that behave like workload identities, this course is a practical place to start.

This post draws on content published by WorkOS: Fetch GitHub repo data without OAuth using WorkOS Pipes. Read the original.