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

A platform team standardizing on least privilege for Slack faces two credential systems with incompatible lifecycles: OAuth 2.0 token rotation for installed app tokens, and the long-lived bearer token issued for SCIM provisioning.

Rotation is opt-in and produces short-lived access tokens with single-use refresh tokens; SCIM tokens carry no expiration and can only be revoked manually. Dead credentials surface as 401 responses with invalid_auth or token_revoked, but there is no API to query a token's remaining lifetime, and a failed or concurrent refresh can leave an installation with no valid tokens. SAML SSO session limits, meanwhile, do not touch tokens already issued.

Open questions

• Can one expiry-and-revocation policy realistically govern both credential types, or do they need separate lifecycles and monitoring?
• When a refresh fails mid-rotation, is reinstallation the only documented recovery path?
• Should the offline scope required for rotating user tokens be treated as a least-privilege exception, and on what basis?

Behavior described here reflects Slack's developer documentation at the time of writing; the OAuth, token rotation, and SCIM pages should be re-checked before this policy is finalized.