掲題の通り、パブリッククラウドサービス（例えばSaaS）などにおけるAPIトークンの基本中の基本について書きます。Webサービス（SaaS）からダウンロードしたCSVファイルが文字化けしている問題の解決方法、そして何故この問いが発生し続けるのか問題に続いてWebの基本の記事です。筆者に何があったのでしょうか。知らんけど。
前提
パブリッククラウドサービスなどにおけるAPIトークンの概要について書きます。アプリケーションの厳密な動作の話ではなく、主にセキュリティの基本について書きます。何も調べずに自分の知識だけで書くので、あとで追記修正する可能性はご容赦ください。
非常に一般論で書きますので、個別サービスなどでの違いが存在する可能性はあります。ご利用のサービスで適宜読み替えてください。
なおAPIトークンはアクセストークンと呼ばれることもある気がしますし、APIキーとの違いも厳密には説明するべきでしょうが、この記事ではAPIアクセスを許可するための機構を一般論としてざっくり「APIトークン」で統一して記述します。
また、APIを狙ったインジェクションやクローリングについても本記事では触れません。あくまで初学者向けの記事です。それらの詳細についてはそのうち書きます。[1]
前置きが多くなりましたので本題に入ります。
APIトークンとはなんですか?
パブリッククラウドサービス（例えばAWSやSlack）の多くは、外部のサービスや自作のアプリケーションから自サービスにアクセスし、データの抽出や認証などの連携窓口を用意しています。SaaS間のデータ連携であったり、kintoneなどで作った自作ツールでHRアプリケーションから従業員データを抽出する、などがこの例に該当します。この窓口が API(Application Programming Interface) です。情報処理技術者試験で習いましたね。
サービス外からアクセスするSaaSやアプリケーションに向けて、アクセスされる側のクラウドサービスが提供する通行手形、それがAPIトークンです。
APIトークンはなんのためにあるのですか?（セキュリティ視点）
セキュリティ視点では、APIトークンの主な役割は 認証（Authentication）と認可（Auththorization） です。認証と認可はアクセス制御の基本であり、これまた情報処理技術者試験で習うので解説は他に譲るとして、APIトークンにおける認証と認可の役割をざっくり解説します。他にもあるけど、あくまで基本的な話です。
例えば、HR系SaaSで外部から従業員データを抽出できるAPIを用意していると仮定します。このとき、認証と認可の役割は以下の通りです。
認証（Authentication）: 「こいつにウチのサービスへのアクセス許していいかな？」「ウチの利用者以外が個人情報を狙ってアクセスしているんじゃ？」「利用者以外は断固通さん！」「いや、こいつはサービスの正規利用者だ」「よし通れ！」これが認証です。
認可（Auththorization）: 「ウチの利用者であることは確認できた」「でもこいつにどこまでアクセス許していいのかな」「従業員番号と名前はOK、給与情報はどうする？」「よし、こいつは給与情報までアクセスを許可する!」これが認可です。
認証と認可というと、ID/パスワード/アクセス権のセットが思い浮かびます。その3点セットが外部公開された認証・認可の情報、これがAPIトークンとざっくり理解すると早いと思います。古き良き時代のアプリケーション開発者視点で言うと、昔はID/パスワードのセットをURLパラメータでリクエストする、デスクトップアプリケーション（例えばVBで作ったやつ）の設定ファイルに書かれたID/パスワードを読み込む、なんてことがありましたが、それらが今のAPIトークンに置き換わっていると理解しています。完全にインターネット老人会です。
APIトークンは誰が発行しますか?
一般的に、サービスの利用者や管理者が発行します。 もう少し説明すると、クラウドサービスでは各種テナントの管理者や類する人が発行することが多いです。AWSなどではアカウントという表現が適切かも。なので「当社のAPIトークンを発行してください！」とAWS公式サポートに必死の形相で問い詰める前に、自社の管理者に訊くべきです。
また、認証・認可という性格上、発行されるユーザーアカウントの権限に基づいたアクセス制御がなされるのが一般的かと思います。[2]
APIトークンが使えなくなりました！どうしたらいいですか?
おま管（お前の管理者）に訊け。
身も蓋もないコメントなのでもう少し。
- クラウドサービスの管理者が、トークンを無効にしていないか
- クラウドサービスの仕様によって、トークンの有効期間が設定され無効になっていないか[1:1]
- トークン発行者のアカウントが削除または無効になっていないか
最後ですが、つまるところ認証と認可が主な機能と考えると、APIトークンの有効性はユーザーアカウントの改廃に基づくと考えた方がいい気がします。
APIトークンは外部公開してもいいですか?
アカン（小声）
先述の通り認証・認可情報なのでみだりに公開はやめましょう。私の好きな校歌を2つ挙げておきます。
「クレデンシャルをSlackに書くな高校校歌」freeeが公開 なぜ作った - ITmedia NEWS
「GitHubにクレデンシャルを書くなソング」 GitHub Japanが公開 話題の「Suno AI」を早速活用 - ITmedia NEWS
おわりに
- APIトークン含むクレデンシャル大事に
- APIに対するDDoSへの対策とか、もっとそういうの書きたい
- 俺、この修羅場が終わったらECサイトのセキュリティ対策とかそういう記事をブログに書くんだ…
追記
SNS他でコメントもらったので追記します。
Q. APIトークンは何が嬉しいのですか？（セキュリティ的な視点で）
A. アクセスを一元的に無効化できるしくみということです。基本的にはふさいでいる、必要なら穴を開けてアクセスを許可する、トークンの有効期限やアカウントの改廃で放っておくとふさがる、そして管理者側の判断で一方的にアクセスを無効化できるという点です。
Discussion