Notifications
Clear all
Topic starter
07/06/2026 8:17 pm
TL;DR: OAuth redirect flows, refresh handling, and token storage are abstracted so applications can request usable access tokens for Google Calendar and other connected services without building credential plumbing themselves, according to WorkOS. That removes implementation burden, but it also shifts trust, scope management, and lifecycle governance into a managed integration layer.
NHIMG editorial — based on content published by WorkOS: Sync Google Calendar events without OAuth using WorkOS Pipes
Questions worth separating out
Q: How should security teams govern brokered OAuth connections in applications?
A: Treat brokered OAuth connections as governed non-human identities.
Q: Why do managed token brokers change NHI governance requirements?
A: They move credential handling out of application code, but they do not remove the credential itself.
Q: What breaks when third-party access is not tied to lifecycle offboarding?
A: Connections can remain active after the user, contractor, or business case has ended, leaving standing delegated access in place.
Practitioner guidance
- Classify brokered connections as governed NHIs Inventory every managed provider connection as a non-human identity dependency, including the owning application, business purpose, scope, and revocation path.
- Bind scope approval to explicit use cases Approve provider scopes only after confirming the data the application actually needs.
- Test reauthorization and disconnect flows Verify what happens when a user disconnects a provider, reauthorization fails, or a token expires before the next backend call.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- Exact widget setup steps for Google Calendar connection management in a Node application
- Backend code for retrieving a fresh provider access token from WorkOS Pipes
- The API request flow for listing Google Calendar events with the returned bearer token
- Provider configuration details for scopes, sandbox credentials, and production OAuth setup
👉 Read WorkOS's tutorial on syncing Google Calendar with Pipes →
OAuth-free calendar sync: what Pipes changes for IAM teams?
Explore further
07/06/2026 10:08 pm
Brokered OAuth shifts NHI governance from code to control plane: Pipes removes the need for every application team to implement OAuth plumbing, but it does not remove the identity problem. The credential still exists, the token still refreshes, and the scope still governs exposure. That means the real control point becomes the integration layer, where storage, rotation, and reauthorization are now concentrated. Practitioners should treat the broker as part of the NHI estate, not as an app convenience.
A few things that frame the scale:
- 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.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How do teams know if delegated scope is staying within policy?
A: Look for scope drift, repeated reauthorization exceptions, and access paths that expand without a new approval decision. If a read-only connection quietly becomes a broader integration pattern, the team is no longer operating at the original policy boundary. Review the scope each time the use case changes.
👉 Read our full editorial: WorkOS Pipes shifts OAuth plumbing into a managed token layer
