【入門編】 API認証におけるAPIキーとOAuthトークンの使い分けとライフサイクル管理 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

皆さん、こんにちは！
日々の開発やインフラの管理、本当にお疲れ様です。セキュリティの世界へようこそ！

初めてAPI（Application Programming Interface）や認証の仕組みに触れるとき、「APIキー」「アクセストークン」「OAuth」といった見慣れない言葉がたくさん出てきて、頭がクラクラしてしまいますよね。

「なんだか難しそう……自分の書いたコードでセキュリティ事故を起こしたらどうしよう」と不安になるかもしれませんが、大丈夫です。一歩ずつ、身近な例えから紐解いていけば、必ずスッキリ理解できるようになりますよ。

今回は、現代のWeb開発で絶対に避けて通れない「APIキーとOAuthトークンの違い」、そして「それらをどう安全に使い、守っていくか」について、現場のリアルな視点も交えながら優しく解説していきますね。

—

1. 家の鍵で例える「APIキー」と「ホテルのカードキー」

まずは、APIキーとアクセストークンの違いを、私たちの身近な「鍵」に例えて考えてみましょう。

APIキーは「玄関の合鍵」

APIキーとは、あなたが「私はこのアプリの制作者（正当な利用者）です！」と証明するための文字列（パスワードのようなもの）です。
これは例えるなら、「実家の玄関の合鍵」のようなものです。一度作ってしまうと、あなたが自ら作り直さない限り、何年経ってもずっと同じ鍵として使えます。

すごく便利ですよね？鍵をポケットに入れておけば、いつでも家に入れます。
しかし、ここに大きな落とし穴（セキュリティリスク）があります。もし、その合鍵をうっかりカフェのテーブルに置き忘れたり、ゴミ箱に捨てたりして、泥棒に拾われたらどうなるでしょうか？
泥棒は、あなたが気づかないうちにいつでも家に入り放題になってしまいますよね。

OAuthトークンは「ホテルの使い捨てカードキー」

一方で、OAuth（オーオーauth）という仕組みで発行される「アクセストークン」は、「ホテルの電子カードキー」にそっくりです。

ホテルに泊まると、チェックインの時にプラスチックのカードキーをもらいますよね。あのカードキーには以下のような特徴があります。

チェックアウトの時間が来ると、自動的に使えなくなる（短命である）
部屋の掃除をする人には「掃除用」、自分には「宿泊者用」と、入れる場所が制限されている（権限が絞られている）
もし紛失しても、ホテルのフロントで無効化して、新しいものをすぐもらえる

APIのセキュリティの世界では、この「ホテルのカードキー」の考え方が主流になっています。「ずっと使える便利な合鍵（APIキー）」は、なるべく隠し場所から出さないようにし、日々の通信には「すぐ期限が切れる安全なカードキー（OAuthトークン）」を使うのが、現代の鉄則なんです。

—

2. なぜ「APIキーの裸の持ち歩き」は危ないのか？

新人の開発者によありがちなのが、フロントエンドのJavaScriptコードや、スマートフォンアプリの中に、以下のような感じでAPIキーを直接書き込んでしまうミスです。

// 【危ない例】JavaScriptの中にAPIキーをそのまま書いてしまう
const weatherApiKey = "AIzaSyC-example-secret-key-123456789";

function fetchWeather() {
  fetch(`https://api.example.com/weather?key=${weatherApiKey}`)
    .then(response => response.json())
    .then(data => console.log(data));
}

一見すると「ちゃんと動くし、何がいけないの？」と思いますよね。
しかし、Webブラウザで動くJavaScriptは、ユーザー（＝世界中の誰でも）が中身を丸見えにできるという性質を持っています。ページのソースコードを表示したり、ブラウザの開発者ツール（F12キーを押して開く画面）のネットワークタブを見たりすれば、この weatherApiKey の文字列は、通りすがりの攻撃者にも一発でバレてしまいます。

もしこのAPIキーに、有料のAIサービスや、ユーザーの個人情報を読み書きする権限が紐付いていたとしたら……。悪意ある人に勝手に使われ、翌月にとんでもない高額請求が届くという、笑えないホロ苦い事件が実際に起きています。

これが、APIキーが狙われる「盲点」なのです。

—

3. 短命なアクセストークン（OAuth）による認可モデルの設計指針

では、APIキーをむき出しにせず、どうやって安全にAPIを叩けばよいのでしょうか？
ここで登場するのが、「一度、身元を証明して、短命なパスポート（アクセストークン）を発行してもらう」というOAuthの仕組みです。

大まかな流れはこうです。
1. ユーザーがIDとパスワードで安全にログインする。
2. 認証サーバーが「この人は本物だ」と確認し、有効期限が例えば「1時間だけ」のアクセストークンを発行する。
3. アプリはそのアクセストークンを使ってAPIにアクセスする。
4. 1時間が過ぎたら、トークンは自動的にゴミになり、使えなくなる。

これなら、もし運悪く1時間の間にトークンが盗まれたとしても、被害は最小限に抑えられますよね。

実装のヒント：HTTPヘッダーでの受け渡し

APIにアクセスするとき、アクセストークンはURLのパラメータ（?key=...など）に含めるのではなく、HTTPリクエストヘッダーの Authorization という場所に載せるのが世界標準のルールです。

PHPを使った簡単なバックエンド側の受け取り・検証のイメージを見てみましょう。

<?php
// リクエストヘッダーから Authorization を取得する
$headers = apache_request_headers();
$authHeader = isset($headers['Authorization']) ? $headers['Authorization'] : '';

// 「Bearer [トークン文字列]」という形式で送られてきているかチェックする
if (preg_cat('/^Bearer\s(\S+)$/', $authHeader, $matches)) {
    $accessToken = $matches[1];

    // ここでアクセストークンの有効期限や署名（JWTなど）が正しいか検証する
    if (validateAccessToken($accessToken)) {
        echo json_encode(["status" => "success", "data" => "機密データを返却します"]);
    } else {
        http_response_code(401); // 401 Unauthorized
        echo json_encode(["error" => "トークンの有効期限切れ、または不正なトークンです。"]);
    }
} else {
    http_response_code(400);
    echo json_encode(["error" => "Authorizationヘッダーが正しくありません。"]);
}
?>

このように、コード側でも「正しく鍵が提示されているか」「有効期限内か」を厳しくチェックすることが、堅牢なAPIを作るための第一歩になります。

—

4. 現場で役立つライフサイクル管理の鉄則

最後に、インフラや開発の現場で私たちが実践している、APIキーとトークンのライフサイクル管理（生まれてから消えるまでの管理）のコツをいくつかお伝えしますね。

1. APIキーは「バックエンド（サーバー側）」に隠す
どうしてもAPIキーが必要な場合は、ユーザーから直接見えないサーバーサイド（Node.jsやPHP、Pythonなどの環境）に環境変数として保持させましょう。フロントエンドからは一度自社のサーバーを経由して、安全にAPIを呼び出すアーキテクチャ（BFF: Backend For Frontendなど）を検討してください。

2. 有効期限（TTL）はできるだけ短くする
アクセストークンの有効期限は、セキュリティと利便性のトレードオフですが、基本的には「短ければ短いほど安全」です。例えば、重要な金融系や個人情報を扱うAPIであれば、アクセストークンの寿命は「15分〜1時間程度」に設定し、切れたらリフレッシュトークンを使って裏側で新しく発行し直す仕組みを取り入れましょう。

3. 定期的なローテーション（鍵の差し替え）を行う
長生きなAPIキーを使わざるを得ない場合でも、3ヶ月や半年に1回など、定期的に新しい鍵を発行して古い鍵を捨てる「ローテーション」の習慣をチームに根付かせてください。

—

まとめ

いかがでしたでしょうか？
セキュリティの対策というと、「なんだか難しくて面倒くさそう」と感じてしまうかもしれませんが、本質は私たちが日常生活でやっている防犯（貴重品は見えないところにしまう、合鍵の管理に気をつけるなど）と全く同じです。

APIキーは「大切なしっかり者の合鍵」として、絶対に表に出さない。
日々の通信には「使い捨てのホテルのカードキー（短命なアクセストークン）」を使う。

この2つの基本原則を頭の片隅に置いておくだけで、あなたの作るシステムは劇的に安全になります。
一歩ずつ、焦らず確実にセキュアな開発スキルを身につけていきましょう！応援しています！