【API認証・認可編】APIキー・OAuth・JWTの役割と守り方｜CTF思考フレームワーク #35

こんにちは、アンペンです！

前回は、依存ライブラリを狙うソフトウェアサプライチェーン攻撃を扱いました。

今回は、ネットワーク・サーバ編の最後としてAPI認証を見ていきます。JWT・OAuth・APIキーが破られる典型場面と、その守り方を学びましょう。

APIキーって長くて複雑な文字列だよね？それでも破られるの？

鍵そのものは強くても、扱い方を間違えると簡単に漏れたり偽造されたりするんだ。JWT/OAuth/APIキーの3方式、それぞれに典型的なミスがあるよ。

ネットワーク・サーバ編もいよいよ最終回。締めくくりは、APIの“入口の鍵”——JWT・OAuth・APIキーです。これらの鍵は、暗号としてはとても強く作られています。なのに、現場では破られる。理由は鍵の強さではなく、“扱い方”にあるんです。今日は会社の入館証のたとえで、『精密な鍵が、運用のスキで台無しになる』典型場面と、その防ぎ方を見ていきます。

3方式の役割と性質

API認証の3方式は、それぞれ向き不向きがあります。

• APIキー：機械間通信向け。長く強い文字列だが、漏洩したらそれっきり
• JWT：署名付きトークン。サーバ間で状態を持たずに認可情報を伝えられる
• OAuth：サードパーティに権限委譲する手続き。アクセストークンを発行する仕組み

仕様自体は安全に作られていますが、実装と運用で『仕様通りでない使い方』が混入すると、簡単に破られます。

ここがこの回のいちばんの肝。これらの鍵は、仕様（設計図）そのものは、世界中の専門家が検証した堅牢なものです。つまり“設計が悪い”わけではない。破られるのは、いつも“使う側”の段階です。検証を一手間サボる、有効期限を無限にする、鍵をうっかり公開する……。鍵が金庫レベルでも、ドアを開けっ放しにしたら意味がないですよね。だから今日の主役は、暗号の中身ではなく『運用と実装のスキ』なんです。

まず3つの鍵を、ざっくり役割で押さえましょう。『APIキー』は、機械と機械が会話するための合言葉。シンプルだけど、漏れたら一巻の終わり。『JWT』は、“偽造できない封筒に入れた身分証”のようなもので、サーバ間で持ち回れる。『OAuth』は、「この人に、私の代わりにここまでやらせていい」と権限を貸し出す手続きです。用途は違いますが、共通するのは“正しく扱えば強く、雑に扱えば即破られる”ということ。

図解：JWT正常検証 vs alg=none偽造

JWTでよく知られる例: ヘッダの alg を none にした偽トークンを、サーバが署名検証なしで受け入れてしまうケースです。

「そんな単純なミス、今どき残ってる？」と思うかもしれませんが、これは古いライブラリやコピペ実装で今も顔を出します。“有名な手口ほど、もう対策されているはず”という油断が、かえって穴を残すこともあるんです。

alg=none の話は、入館証のたとえがぴったりです。JWTには「この封筒は、こういう方式で封がしてあります」という指定欄（alg）があります。ところが、ここに「封なし（none）」と書いて送ったとき、古いサーバは「なるほど封なしね、じゃあ中身は信用しよう」と、検証せずに通してしまうことがある。封がされていないのに本物扱い——警備員が“封のない入館証”をスルーするようなものです。だから現代の実装は、許す封の方式をあらかじめ決めておき、それ以外（noneを含む）は問答無用で弾きます。

方式別の典型ミス

3つの鍵には、それぞれ“ありがちな落とし穴”があります。JWTは『署名の検証を甘くする』、OAuthは『途中の手続きを省く（stateなしなど）』、APIキーは『うっかり外に出す・期限を切らない』。技術は違っても、根っこは同じ——“仕様の手順を、つい一部はしょってしまう”ことです。一つずつ見ていきましょう。

代表的な3方式のつまずき

• JWT： alg=none 許可、アルゴリズム混乱(HS256/RS256混在)、署名検証スキップ、長すぎる有効期限
• OAuth： state パラメータなし(CSRF)、リダイレクトURI緩い、暗黙フロー(implicit)残存、PKCEなし
• APIキー： リポジトリへのコミット漏洩、有効期限なし、平文ログ出力、過剰な権限

これらは『実装と運用で発生』するため、ライブラリ任せだけでなく、設計レビューで早めに見つけることが重要です。

中でも、いちばん多くて、いちばん地味にやられるのが『APIキーのうっかり公開』です。便利だからとコードに直接キーを書き込み、そのままGitHubに上げてしまう——これは本当によくある事故。公開リポジトリのキーは、自動巡回するボットに数分で見つかって悪用される、と言われるほどです。高度な攻撃ではなく“置き忘れ”。だからこそ、シークレットを自動で検出する仕組み（コミット前チェック）が、地味にいちばん効くんです。

練習は、自分のAPIの認証まわりを“チェックリストで点検”することです。JWTはnoneを弾いてる？OAuthはstateを必須にしてる？APIキーがコードに紛れ込んでない？——攻撃ではなく健康診断ですね。もちろん他人のAPIにトークン改ざんを試すのは厳禁。自分の環境とCTFの中で、仕様どおりに使えているかを一つずつ確かめましょう。

CTFでやってみよう：API認証実装を点検

守りで意外と軽視されがちなのが『有効期限』と『回転（ローテーション）』です。

鍵を強くして漏らさなければ、有効期限なんて無限でもいいんじゃない？

気持ちは分かるけど、それは“一度も漏れない前提”に賭ける危うい考え方なんだ。現実には、ログに残ったり、退職者の端末に残ったり、と鍵はじわじわ漏れる。そこで効くのが、短い有効期限と定期的な“鍵の交換”。たとえ漏れても、すぐ期限が切れたり、次の交換で無効になれば、使える時間はごくわずか。鍵は“いつか漏れるもの”と考えて、漏れても短時間で無力化できる仕組みを作る——これが運用の勘どころだよ。

守る側なら、「仕様通り+ライフサイクル+最小権限」

API認証の守りは、「仕様通りに実装」「発行・失効・回転のライフサイクル」「権限スコープの最小化」の3点が中心です。

『鍵を強くする』だけじゃなく『どう扱うか』まで含めて守るんだね。

そう。鍵の世界では『運用』が一番効く。ライフサイクル管理を仕組み化しよう。

ここまでをひと言で言うと、API認証の守りは『鍵を強くすること以上に、鍵の“扱い方”を整える』こと。仕様の手順を省略しない、期限を切って定期的に交換する、権限は最小限に絞る。どれも派手さはありませんが、“鍵そのもの”より“運用”でやられる、というこの分野の現実に、ちょうど効く守りです。

まとめ：API認証は『運用』が9割

今日の持ち帰りは『鍵は、強さより“扱い方”』です。どんなに頑丈な鍵も、検証を省いたり、置き忘れたり、永遠に使い回したりすれば、簡単に破られます。仕様どおりに検証し、短い期限で回し、最小権限に絞る。この“当たり前の運用”こそが、API認証のいちばんの守りになります。

ここでネットワーク・サーバ編(#21〜#35)はひと区切りです。次回からは、すでに侵入されたあとの動きを扱う侵入後フェーズ(#36〜)に入ります。最初は資格情報窃取(LSASS・SAM・DPAPI)を見ていきましょう。

次に読みたい記事

参考資料