There are more than a few tokens in the Slack platform. A token ties together all the scopes and permissions your app has obtained.
Each token type may only obtain certain scopes. Your app might make use of multiple types of tokens, especially if the app acts in a few different ways.
There are also a few legacy token types that allowed actions that are now deprecated.
Read up on the different types of tokens, and the permissions they can contain, next.
Bot user tokens let your app act independently.
User tokens allow you to work directly on behalf of users, based on the OAuth scopes that installing users award to your app.
Legacy tokens, scopes, and methods are better left to the past.
The bot user model has changed! You'll find more methods and scopes supporting bot tokens than ever before—for most of these you'll need a new kind of more granular bot token.
Bot user tokens represent a bot associated with the app installed in a workspace. Unlike user tokens, they're not tied to a user's identity; they're just tied to your app.
Since acting independently allows your app to stay installed even when an installing user is deactivated, using bot tokens is usually for the best.
Check out the guide to new Slack apps for more info.
- Bot user token strings begin with
- New bot users can request individual scopes, similar to user tokens. Older bot tokens requested an umbrella
botscope with many different permissions included it.
- Older bot user tokens can't have resource-based OAuth scopes added to them, any scopes other than
botrequested during the OAuth installation flow have no effect on the bot user token
- Revoking an older bot user token with
auth.revokedoes not uninstall the bot user. A new token may be obtained via OAuth or, for internal integrations, your app management console.
User tokens represent workspace members. They are issued for the user who installed the app and for users who authenticate the app. When your app asks for OAuth scopes, they are applied to user tokens. You can use these tokens to take actions on behalf of users.
- User token strings begin with
- User tokens gain the "old world" resource-based OAuth scopes requested in the installation process (example: asking for
channels:historygrants a user token access to
conversations.historyfor any public channel)
- User tokens represent the same access a user has to a workspace -- the channels, conversations, users, reactions, etc. they can see
- Write actions with user tokens are performed as if by the user themselves
App-level tokens represent your app across organizations, including installations by all individual users on all workspaces in a given organization.
These tokens give you the ability to handle things that relate to your app as a whole, like listing all the authorizations an event is visible to.
The developer preview for workspace apps has ended. We're taking the components of workspace apps and breaking them apart: applying them in phases to existing as well as new apps. Read more about the motivation behind ending the preview.
For those who already have an existing app using a workspace token, here's a quick overview on how they work:
- Workspace access token strings begin with
- Workspace refresh token strings begin with
- Access tokens are the only tokens used to call an API method.
- Use your refresh token to rotate and refresh your access token with no downtime.
- Bot users and bot user tokens cannot be used in conjunction with workspace tokens.
- No requests are made on behalf of users with workspace tokens.
- OAuth scopes negotiated during the OAuth installation process or through the Permissions API are applied directly to your workspace token.
These tokens were associated with legacy custom integrations and early Slack integrations requiring an ambiguous "API token." They were generated using the legacy token generator and are no longer recommended for use. They take on the full operational scope of the user that created them.
Verification tokens are deprecated. Use the more secure signing secret to verify Slack requests for authenticity.
Verification tokens weren't like these other token types. They weren't really tokens at all.