Notifications
Clear all
Topic starter
07/06/2026 7:56 pm
TL;DR: OAuth plumbing needed to send Slack notifications from SaaS apps can be removed, with token storage, refresh, and per-user workspace connections handled so developers can post messages with a fresh access token, according to WorkOS. The identity lesson is that delegated access still needs governance even when the implementation is abstracted away.
NHIMG editorial — based on content published by WorkOS: Send Slack notifications from your app without building OAuth
Questions worth separating out
Q: How should security teams govern Slack integrations that use delegated workspace access?
A: Treat each connection as a scoped identity relationship with an owner, purpose, and revocation path.
Q: What breaks when a Slack token is hidden behind a convenience layer?
A: What breaks is visibility into the token lifecycle.
Q: How do you know if per-user Slack connections are actually governed?
A: You should be able to answer three questions quickly: who owns each connection, what scopes it has, and when it was last validated or removed.
Practitioner guidance
- Inventory delegated SaaS connections as NHI assets Record every per-user Slack workspace binding, the scopes granted, the owning application, and the business purpose for the connection.
- Separate channel discovery from message posting Use channels:read only for channel selection workflows and chat:write only for notification delivery.
- Build revoke-and-reconnect handling into the workflow When token retrieval fails, route users back to the integrations page and mark the connection as inactive until they reconnect.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- The full Node.js and React code path for embedding the Pipes widget and generating widget tokens
- The exact Slack OAuth scope configuration steps for message posting and channel discovery
- The backend helper functions for retrieving fresh access tokens and handling reconnect failures
- The end-to-end notification flow from deployment event to Slack message delivery
👉 Read WorkOS's tutorial on sending Slack notifications without OAuth plumbing →
Slack notifications without OAuth plumbing: what changes for IAM teams?
Explore further
07/06/2026 9:40 pm
Abstracting OAuth does not remove the identity problem, it relocates it. The application still depends on delegated access, token freshness, and revocation handling even when those controls are hidden behind a widget. That means the security conversation shifts from implementation burden to governance ownership, because the credential lifecycle is still present even if developers never write the plumbing. Practitioners should evaluate who owns the trust boundary, not just who writes the code.
A few things that frame the scale:
- 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
- Around 100,000 valid secrets were found in public Docker images, with ENV instructions alone accounting for 65% of all secret leaks in containers.
A question worth separating out:
Q: Should organisations allow Slack notifications to be sent on behalf of users?
A: Yes, but only when the business need is clear and the identity controls are explicit. Use user-scoped permissions, avoid broader workspace access than necessary, and make reconnection mandatory after revocation or uninstall events. If the notification workflow cannot tolerate those constraints, it should not be allowed to persist.
👉 Read our full editorial: WorkOS Pipes reduces OAuth overhead for Slack notifications
