Tokens, Scopes & OAuth
The token taxonomy, the minimal-scope principle, and why this site skips the OAuth redirect flow
Token Taxonomy
| Token | Prefix | Represents | Typical use |
|---|---|---|---|
| Bot token | xoxb- | The app's own bot user | Almost everything -- a stable identity independent of any individual member |
| User token | xoxp- | A specific workspace member | Actions that must appear as performed by that person |
| App-level token | xapp- | The app itself, across every workspace it's installed in | Socket Mode (connections:write) and other app-wide operations |
| Workflow token | xwfp- | A single Workflow Builder step, briefly | Reading data inside that step only -- expires 15 minutes after issuance or when the step finishes, whichever comes first |
Taxonomy per Tokens. This site's patterns default to the bot token -- it's the only one of the four that isn't tied to a person, a workflow run, or Socket Mode.
Workflow tokens and the Lists API
xwfp tokens carry "borrowed visibility" into channels the workflow's initiator can see but the bot user isn't a member of -- useful inside Workflow Builder, but at least one community report shows a workflow-token call against slackLists.access.set returning list_not_found where the same call on a bot token would work (slackapi/deno-slack-sdk#472). That's not documented Slack behavior, just a field report -- treat it as a reason to keep list writes on the bot token rather than a workflow token. See Lists: Access & Scopes for the list-specific access model.
Minimal Scope
Request only the bot scopes a feature actually uses, and add more later rather than everything up front -- scopes are additive on reinstall (below), so there's no cost to growing the list over time, and every unused scope is a permission you'd have to justify if the workspace admin ever audits installed apps (Installing with OAuth).
Installing Without An OAuth Redirect
Slack's OAuth v2 flow exists to let any workspace install your app: the user is redirected to Slack, approves the requested scopes, and Slack redirects back to a URL your server hosts with a temporary code your server exchanges for a token. None of that applies to an app that only ever runs in the one workspace you built it for. Clicking Install to Workspace on the app's own OAuth & Permissions page is the installation -- Slack issues the token immediately and shows it on that same page, with no redirect URL, no code exchange, and no server-side callback to write (App distribution).
When OAuth Is Needed
The full redirect flow matters once the app leaves your workspace: public distribution (any workspace can install it via a shareable link) and org-wide internal distribution (installable across every workspace in an Enterprise Grid org) both require implementing the redirect endpoint, because Slack has no other way to hand your server a token for a workspace it doesn't run in. Multi-workspace distribution is out of scope for this release -- everything here assumes a single, known workspace.
Reinstalling After A Scope Change
Scopes are additive: requesting a new scope and sending the workspace through install again adds it to the existing grant rather than replacing it, and there's no way to downgrade a token's scopes short of reinstalling with a smaller manifest (Installing with OAuth). In practice: edit the manifest or the scope list on OAuth & Permissions, then click Reinstall to Workspace. Reinstalling issues a new bot token -- the old one stops working, so update the stored Worker secret in the same change (Worker Backend: Secrets & Config).