Slack OAuth Token Rotation and SCIM Bearer Tokens: One Expiry Policy or Two?

Answer first

No. One unified expiry-and-revocation policy cannot realistically govern Slack OAuth 2.0 token rotation and SCIM bearer tokens together. They have incompatible lifecycles and revocation mechanisms. Treat them as two separate credential classes with separate monitoring and runbooks.

Confirmed facts

• Slack installed app OAuth 2.0 token rotation is opt-in. When enabled, access tokens are short-lived and each refresh token is single-use. A new refresh token is issued on each refresh.
• Token rotation requires the offline scope to obtain a refresh token. Without it, no rotation is possible.
• SCIM provisioning bearer tokens are long-lived with no default expiration and no expires_in field in the issuance response. They can only be invalidated by manual revocation in the admin console or via the admin revocation API.
• No API exists to query remaining lifetime for either OAuth refresh tokens or SCIM bearer tokens. Dead credentials are detected only via error responses such as invalid_auth or token_revoked from API calls.
• SAML SSO session limits do not affect already issued OAuth or SCIM tokens.

Likely explanation for the mismatch

OAuth rotation is time-bound and refresh-driven. SCIM is persistent until manual action. Because SCIM tokens never expire automatically, a single expiry policy would either force artificial expiry on OAuth tokens or leave SCIM tokens with no automated expiry at all. Failed or concurrent refresh attempts can consume the single-use refresh token and invalidate the current access token, leaving the installation without a valid credential until a new authorization is completed.

Steps needed for this case

1. Separate lifecycles. Keep OAuth rotation monitoring focused on access token expiry, refresh token single-use success, and re-authorization health checks. Keep SCIM monitoring focused on manual revocation events and periodic credential rotation by policy.
2. Monitoring. Implement client-side health checks that record 401 invalid_auth / token_revoked responses. For OAuth, alert on consecutive refresh failures. For SCIM, alert on provisioning failures and maintain an inventory of active SCIM tokens with last-used timestamps.
3. Recovery. Document a re-authorization flow for OAuth installations after a failed rotation. Reinstallation or a fresh OAuth authorization with the required scopes is the documented recovery path when both access and refresh tokens are invalid.
4. Least privilege for offline. Treat offline as a required exception for any app that needs persistent background access. Do not grant it to user-facing only flows. Document the exception and review it on each app.

Uncertainty note: Slack documentation is the source of truth and changes over time. The behavior described reflects developer documentation at time of writing and requires current verification before finalizing policy.

One diagnostic detail that changes the recommendation: are the OAuth installed app tokens and the SCIM bearer token managed by the same app installation and workload? If they are separate services, isolation is simpler. If they are co-managed, the risk of a single failure cascading to both provisioning and app access increases.