Option D combines two important Slack security principles: least privilege and restriction of credential use. Applications should request only the OAuth scopes that are genuinely required. Every unnecessary scope expands what a compromised token could access or modify, so eliminating unused permissions materially reduces exposure. Slack additionally allows developers to restrict Web API token usage to an allowlist of trusted source IP addresses. Requests using the protected token from addresses outside the configured ranges are rejected. This creates an additional control around bearer-token misuse if credentials are accidentally exposed. Base64 encoding is not encryption and offers no meaningful protection for a leaked token, making A and B insecure. Credentials must not be embedded directly in application source code or committed to repositories. They should instead be kept in appropriate secret-management or environment-based facilities. Periodically uninstalling and reinstalling an application is also not a recognized credential-security strategy. Slack further recommends token rotation where appropriate. With token rotation enabled, granular access tokens expire and are exchanged using refresh tokens, reducing the useful lifetime of a stolen access token. Therefore, D is the strongest choice and directly aligns with Design for Security, including least-privilege scopes, credential protection, IP restrictions, and token lifecycle security.