SlackとAltaryの連携を進めるにあたって

自社サービス「Altary」のSlack連携を本格的に実装するタイミングで、アクセストークンの管理や自動更新の仕組みが必要となり、OAuth 2.0フローの見直しを行いました。

特に今回は、Slack上で「Bot としてではなく、ユーザー本人として」投稿する機能が必要だったため、User Tokenの活用を前提に設計を進める方針でした。

調査段階で直面した疑問：User Tokenでもトークン更新は可能か？

OAuthの運用において避けて通れないのが、トークンの有効期限とリフレッシュ処理です。

当初、ChatGPTに以下のような質問を投げかけました：

「SlackのUser Tokenでrefresh_tokenを使ったトークン更新はできますか？」

その回答は明確で、以下のように「使えない」とのことでした。

User として投稿したい場合は xoxp-（User Token）を使う必要がありますが、refresh_token は使えないため、トークンは自前で再取得管理する必要があります。

疑問に感じたため、Slackの公式ドキュメント（Token Rotation）を改めて確認したところ、以下の記述が明確に存在していました。

Either a granular bot token or user token may be exchanged for a refresh token and expiring access token.

つまり、User Token であっても refresh_token による更新がサポートされているということです。

実際にUser Tokenでの認証とトークン交換を試みたところ、下記のようなレスポンスが返ってきました。

{
  "access_token": "xxxx-xxxx",
  "refresh_token": "xxxx-xxxx",
  ...
}

結果として、User Token においても Token Rotation が正常に機能することが確認できました。

ChatGPTをはじめとした生成AIは、構文や処理の例示など、日常的な開発支援には非常に有用です。

しかし今回のような「仕様の可否や運用ポリシー」に関わる部分に関しては、信頼性の高い一次情報（公式ドキュメント）による裏付けが不可欠であると改めて感じました。

生成AIのトレーニングデータは更新にタイムラグがあることも多く、情報が古い場合もあります。
また、かつての制限や非推奨事項がそのまま残っているケースもあり、注意が必要です。

Slack APIに限らず、外部サービスとのOAuth認証やセキュリティ仕様に関しては、実装前に公式ドキュメントを確認することを前提とすべきです。

今回のケースでは、ChatGPTの回答を鵜呑みにしていたら、設計をBot Token中心に切り替えてしまい、不要な実装変更やユーザー体験の低下につながるところでした。

生成AIはあくまで「補助ツール」として活用し、判断の根拠となる情報は常に一次ソースで確認することの重要性を、実体験として再認識できた良い機会だったと思います。

開発中のバグレポートアプリ「Altary」から、バグレポートを簡単にSlackに送信できるようになりましたので、ぜひ使ってみてください！