Keeping credentials secure is important whether you're developing open source libraries and tools, internal integrations for your workspace, or Slack apps for distribution to workspaces across the world.
Even if you're not working with OAuth 2.0 and user access tokens, please consider these safety suggestions when working with the Slack Platform.
As a Slack App developer, you'll be working with credentials issued to you from Slack, as well as token values representing members, workspaces, and specific features of your application.
Your Client ID is one piece of information used to identify your application and frequently appears in OAuth negotiation URLs and other contexts. Your Client ID can be shared freely in code and email and cannot be used alone to act on your application's behalf.
Your Client Secret should be treated delicately. It is how you securely identify your application's rights and identity when exchanging tokens with Slack. Do not distribute client secrets in email, distributed native applications, client-side javascript, or public code repositories.
These tokens represent specific access levels granted by the OAuth scopes you negotiated.
Bot user tokens can connect to the real time messaging API and post messages on their own behalf. They can also access a subset of API methods to better understand the channels, members, and messages received as part of its activities.
User tokens, such as those received through the Add to Slack and Sign in with Slack flows are capable only of the permissions granted to it during the OAuth flow using scopes.
Store user and bot user tokens with care and never place them in a public code repository or client-side code like Javascript.
One way to build confidence in the sanctity of your user and bot tokens is to lock down their usage to a known set of IP addresses you control: allowed IP lists.
Restricting token use by IP address only applies to token use against the Web API for internal integrations and apps that have been explicitly marked as undistributed. Allowed IP listing does not apply to incoming webhooks.
By providing a list of allowed IP addresses, Slack will only accept requests to Web API methods if originating from a listed IP address. If the request matches your allowed list, Slack will execute the request and respond as usual.
If the request originates from an IP address not listed in your allowed list, it will be rejected with this response:
{
"ok": false,
"error": "invalid_auth"
}
Navigate to your application management and select the OAuth & Permissions pane. The Restrict API Token Usage section allows you to specify an allowed list of acceptable public IP addresses.
Up to ten entries are allowed. Each entry specifies either a CIDR range of IP addresses or a single IP address.
For example:
101.101.101.106 will allow only that IP address, which we'll consider as 101.101.101.106/32.101.101.101.0/24 will allow all 256 IP address between 101.101.101.0 and 101.101.101.255."Local" IP addresses cannot be added to allowed lists and IPv6 is not supported.
Slack also supports several ways to verify the authenticity of its requests to your app. Read more in the verifying requests from Slack documentation.
Read more about on how to use token rotation for new and existing Slack apps.
Revoke tokens manually with auth.revoke.
Slack app-based incoming webhook URLs allows posting messages only to a specific channel configured by the approving member. Their identity is always tied to the application associated with the URLs and cannot be used as arbitrary users or on unapproved channels.
Redirect URIs appear as URLs and are safe to be part of published code. However, ensure that the redirect URIs defined in a public application are limited only to domain names in your direct control.
We recommend that after you complete local development, remove localhost and related domains from your configuration list.
Storing authentication secrets is difficult, and how you do it best depends on context, usage, and design requirements. While it would be super cool if all tokens were encrypted with individual keys controlled by the customers, most implementations do not allow that. Here are some things to consider when storing tokens to ensure that we're doing everything we can to prevent accidental exposure or mix-up of usage.
The 7-Layer OSI model breaks out how applications and computers function over a network and can provide a useful model for thinking about security at each layer. By breaking apart each layer, it's possible to look at different risks and mitigations to best apply.
The Application layer is mostly focused on high-level APIs, and how your application exposes itself to an end user. Here are some things to consider:
These layers encompass most of the non-application-based internet-plumbing, including protocols such as TCP, IPv4, MAC, and Ethernet. We're going to assume for safe token usage and storage that these layers are already secured, however there are a few points to consider, especially if you are hosting in the cloud.