Notifications
Clear all
Topic starter
12/06/2026 9:21 pm
TL;DR: GitLab connection handling, token storage, and refresh logic can be moved out of the application and into a managed layer, letting developers request a fresh access token and call the provider API directly, according to WorkOS. That reduces implementation friction, but it also concentrates third-party access governance and secret-handling assumptions in one control point.
NHIMG editorial — based on content published by WorkOS: Connect your app to GitLab without building OAuth
Questions worth separating out
Q: How should security teams govern OAuth-based integrations with third-party services?
A: Security teams should govern OAuth integrations like any other delegated identity relationship.
Q: Why do managed token services still create identity governance risk?
A: Managed token services still create risk because they do not remove delegated access, they centralise it.
Q: What is the difference between API filtering and least privilege?
A: API filtering limits what results are returned, while least privilege limits what the token can do in the first place.
Practitioner guidance
- Map delegated integration ownership Assign a business owner and technical owner for every external service connection, including who approves scopes, who reviews renewal events, and who disables the integration when the use case ends.
- Review OAuth scopes as entitlements Treat provider scopes as access entitlements that need documented justification, periodic review, and revocation criteria, especially when one token can reach multiple API endpoints.
- Separate output filtering from authorization Validate that query parameters such as membership filters do not create a false sense of least privilege, because the underlying token still carries the granted scope.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup of the Pipes widget, including dashboard configuration and provider selection.
- Node code examples for fetching a refreshed GitLab access token from the backend.
- Specific GitLab API calls and query parameters used to list user projects.
- Practical implementation notes for handling token expiry and reconnect flows.
👉 Read WorkOS's tutorial on connecting GitLab through Pipes →
GitLab OAuth without the plumbing: what does Pipes change?
Explore further
12/06/2026 11:21 pm
Managed OAuth does not remove identity risk, it relocates it. Workflows that push OAuth handling into a platform still depend on delegated third-party access, scope discipline, and secure token handling. The governance burden moves from application code to platform configuration and lifecycle oversight. That means IAM and security teams must still know who can connect services, what each scope allows, and when access should be revoked or reauthorized. The practitioner conclusion is simple: abstraction reduces engineering effort, not accountability.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: When should organisations reauthorise external service connections?
A: Organisations should reauthorise external service connections when the business purpose changes, the user’s role changes, the connected provider changes scope requirements, or the integration has been idle for an extended period. Reauthorisation is the point where governance can confirm that the access still matches the current need. Without it, delegated credentials can persist well beyond their intended use.
👉 Read our full editorial: WorkOS Pipes shifts GitLab OAuth handling to managed token flow
