API 認証方式完全ガイド：Basic Auth から OAuth2.0、JWT まで

毎朝、前扉を全開にして家を出かけ、「フリーウィ-Fi、フリースナック、セキュリティカメラなし！」という大きなネオンサインを点灯させるなんて、考えただけでもicrous ですよね。

でも、適切な認証のない API を構築すると、まさにそんな状態と同じです。

API はアプリケーションの最重要データへの入り口——ユーザープロファイル、課金情報、制作中の猫の動画など——インターネットは、誰もが犬の散歩に興味津々というよりは、基本的に大きなデジタル地域社会のようなものです。

適切なロックや鍵、身分確認なしに、あなたの API はボットや悪意ある第三者、そして「間違って」ステージングトークンを本番環境に入力する同僚の一人にとって、ブッフェテーブルのような存在になってしまいます。

このガイドでは、API 認証の荒野を分解します：

Basic Auth のようなシンプルな ID カード風のログインから、AWS シグネチャ V4 のような 007 のような暗号化された署名まで。何を使うべきか、什么时候に使うべきか、最も重要なのは——あなたの API を勝手に食べ放題のハッカーブッフェにしないようにする方法を示します。

Marketing 用の説明：エンドポイントの完全な Fort Knox 化を行います。

API 認証の荒野

1. クールな子供たちのクラブ：現代の認証方式（2020 年代のアプリにもう適したものです）

2. 「古き良き」グループ：Basic およびレガシー認証（内部使用や、昨日ボスに求められた MVP に適しています）

3. フォートノックス・グループ：署名済み & シール済みセキュリティ（神経質な方やフィンテック業界向け）

4. 内部事務：独自およびエンタープライズ認証（コーポレートな設定や Windows の懐かしさ向け）

5. テストツール & 開発者のショートカット（トークンを 100 回も入力するのは嫌でしょう）

認証方式の掘り下げ——メタファー付き

1. Basic Auth——クラシックなユーザー名 & パスワード

アナロジー：警備員に「502 号室のジョンです」と言ったら、入れてくれるようなものです。

主要な特徴：

• 各リクエストにユーザー名とパスワード（Base64 エンコード済み）を送信する
• 超シンプルだが、セキュリティ的には最悪——認証情報は簡単に傍受される可能性がある
  使用シチュエーション：信頼できる環境で（例えば内部ネットワークやテスト時）

最適な用途：内部システム、小規模チームツール
リクエスト例：

GET /api/data HTTP/1.1  
Authorization: Basic am9objpwYXNzd29yZA==  # Base64 エンコードされた john:password

Python 例：

import requests
from requests.auth import HTTPBasicAuth

requests.get('https://api.example.com/data', auth=HTTPBasicAuth('john', 'password'))

2. ベアラートークン——シンプルなアクセスパス

アナロジー：ジムのメンバーシップカードを使うようなもの——誰も名前を確認しない、カードの有効性だけを確認する。

主要な特徴：

• トークンがセッションを表す
• ユーザー情報は含まず——単なる認可の証明のみ
  使用シチュエーション：ログイン後、ユーザー固有のデータにアクセスする場合

最適な用途：ログイン後の認証済み API アクセス
リクエスト例：

GET /api/profile HTTP/1.1  
Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...

JavaScript 例（フロントエンド）：

fetch('/api/profile', {
  headers: {
    'Authorization': 'Bearer YOUR_TOKEN_HERE'
  }
})

3. JWT Bearer——スマートな ID バッジ

アナロジー：名前、写真、役職が記載された ID カード——単なるパスではなく、情報も持っている。

主要な特徴：

• 自己完結型トークンでユーザー情報（JSON Web Token）を含む
• 毎回データベースにアクセスする必要がない
  使用シチュエーション：マイクロサービス、シングルサインオン、ステートレスアプリの場合

最適な用途：マイクロサービス、シングルサインオン
トークンペイロード：

{
  "sub": "user123",
  "role": "admin",
  "exp": 1710000000
}

Node.js 例：

const jwt = require('jsonwebtoken');
const token = jwt.sign({ user: 'john' }, 'secret', { expiresIn: '1h' });

fetch('/api/data', {
  headers: {
    Authorization: `Bearer ${token}`
  }
});

4. API キー——ホテルの部屋のキーカード

アナロジー：ホテルの部屋に入るためにキーカードが必要です。

主要な特徴：

• 呼び出し元を識別するための一意の文字列
• ヘッダー、クエリ、または本文経由で送信可能
  使用シチュエーション：簡単なアクセス制御や使用状況の追跡が必要な場合

最適な用途：公開 API、プラットフォームの使用状況追跡
ヘッダー例：

GET /api/news HTTP/1.1  
x-api-key: abc123456789

クエリストリング例：

GET /api/news?apikey=abc123456789

5. OAuth 2.0——標準的な第三者ログイン

アナロジー：Google アカウントで PayPal にログインする——Google があなたのアイデンティティを保証する。

主要な特徴：

• ユーザーデータへの委任アクセス用
• 複数のフローがサポートされている（認可コード、パスワード、クライアント資格情報など）
  使用シチュエーション：ソーシャルログインや企業間統合の場合

最適な用途：第三者ログインや委任アクセス
簡略化された認可コードフロー：

1. ユーザーが認可ページにリダイレクトされる
2. code を取得する
3. サーバーが code をアクセストークンと引き替える：

POST https://oauth.example.com/token   
Content-Type: application/x-www-form-urlencoded  

grant_type=authorization_code&code=abc123&client_id=xxx&client_secret=yyy

1. トークンを使ってデータにアクセスする：

GET /user/profile  
Authorization: Bearer ACCESS_TOKEN_HERE

6. OAuth 1.0——昔ながらのメソッド

アナロジー：個人的なサインと会社のスタンプの両方が必要——整合性のための余分な手間。

主要な特徴：

• リクエストを署名する必要がある（署名）
• セキュアだが複雑
  使用シチュエーション：API が OAuth 1.0 しかサポートしていない場合（例えば、Twitter）

最適な用途：レガシー API である Twitter の場合
認可ヘッダー：

Authorization: OAuth oauth_consumer_key="key",
                      oauth_nonce="random",
                      oauth_signature="hmac_sha1",
                      ...

Python 例：

from requests_oauthlib import OAuth1

auth = OAuth1('YOUR_KEY', 'YOUR_SECRET', ...)
requests.get('https://api.twitter.com/1.1/statuses/home_timeline.json', auth=auth)

7. ダイジェスト認証——暗号化されたパスワード

アナロジー：ボイスチェンジャーを通じて ID 番号を伝える——声高に叫ぶよりも安全。

主要な特徴：

• Basic Auth よりもセキュア（ソルトとハッシュングを追加）
• 互換性の問題がある
  使用シチュエーション：ユーザー名とパスワードが必要だが、よりセキュアなレガシーシステムの場合

最適な用途：古いエンタープライズバックエンド
Python 例：

from requests.auth import HTTPDigestAuth
requests.get('https://example.com/api', auth=HTTPDigestAuth('user', 'pass'))

8. ホーク——署名済み配達

アナロジー：すべての配達に署名し、中の内容も含めて——読み替えられていないことを確認する。

主要な特徴：

• HMAC 署名がリクエストの整合性を保護
• パスワードは決して暴露されない
  使用シチュエーション：サービス間 API やメッセージの整合性が必要な場合

最適な用途：高セキュリティなサービス間 API
Node.js 例：

const hawk = require('@hapi/hawk');

const credentials = {
  id: 'user-id',
  key: 'secret-key',
  algorithm: 'sha256'
};

const { header } = hawk.client.header('https://api.example.com/resource', 'GET', { credentials });

fetch('https://api.example.com/resource', {
  headers: { Authorization: header }
});

9. AWS シグネチャ——アマゾン公式フォーマット

アナロジー：AWS 本社を訪問？彼らの公式招待状フォーマットが必要です。

主要な特徴：

• タイムスタンプ、ヘッダー、リージョンなど、厳格にフォーマットされたリクエスト署名
• AWS サービスでは必須
  使用シチュエーション：AWS API（S3、Lambda など）と通信する場合

最適な用途：AWS サービスへのアクセス
Python 例：

import boto3

s3 = boto3.client('s3', aws_access_key_id='AKIA...', aws_secret_access_key='...')
s3.list_buckets()

AWS SDK が署名生成を自動的に処理します。

10. NTLM 認証——Windows 内部バッジ

アナロジー：会社のゲートで社員 ID をかざす——内部ネットワークでのみ可能です。

主要な特徴：

• Windows ドメイン認証
• レガシー内部システムで機能する
  使用シチュエーション：Microsoft 環境のエンタープライズアプリケーションの場合

最適な用途：内部 Windows システム
Python 例：

from requests_ntlm import HttpNtlmAuth
requests.get("http://windows-server.local", auth=HttpNtlmAuth('DOMAIN\\user', 'password'))

11. アカマイ・エッジグリッド——大規模なセキュアゲートキーピング

アナロジー：空港セキュリティがゲートを通す前に、あなたのパスが彼らのセキュアフォーマットにマッチしなければならない。

主要な特徴：

• アカマイ固有の署名メカニズム
• セキュアで大規模なトラフィック処理を確保
  使用シチュエーション：アカマイによって保護された API を呼び出す場合

最適な用途：アカマイ背後のエンタープライズ API
認可ヘッダー：

Authorization: EG1-HMAC-SHA256 client_token=xxx;access_token=yyy;timestamp=...;nonce=...

Node.js 例：

const edgegrid = require('akamai-edgegrid');

const eg = new edgegrid('client_token', 'client_secret', 'access_token', 'host');
eg.auth({
  path: '/endpoint',
  method: 'GET'
});

12. ASAP（アトラシアン・サービス・認証・プロトコル）——内部社員バッジ

アナロジー：会社内の部署間を移動する際、スタッフ ID が自動的にアクセスを許可する。

主要な特徴：

• アトラシアンの JWT ベースのサービス間認証
• プライベートキーで署名
  使用シチュエーション：アトラシアン・エコシステム内やマイクロサービス間の内部呼び出しの場合

最適な用途：アトラシアン内部サービス、CI/CD パイプライン
認可例：

Authorization: Bearer eyJraWQiOiJhc2FwS2V5IiwidHlwIjoiSldUI...

13. 親からの継承——ワンログインで全てを支配する

アナロジー：メインモールに入るためにパスを得ると、そこに含まれるすべてのショップが再確認なしで通してくれます。

主要な特徴：

• 子リクエストが親設定から認証を継承する
  使用シチュエーション：EchoAPI のようなツールで、多くのエンドポイントを共有認証でテストする場合

最適な用途：API テストツール（EchoAPI コレクション）
仕組み：コレクションレベルで一度認証を設定すると、すべてのリクエストが自動的にそれを継承する

親コレクションでベアラートークンを設定→すべてのリクエストが自動的に継承される

14. 認証なし——すべてに開放

アナロジー：誰でも入れる公共の公園——ID もチケットも必要ありません。

主要な特徴：

• 一切の認証が必要ありません
  使用シチュエーション：公開データ、開発用スタブ、またはヘルスチェックエンドポイントの場合

最適な用途：公開 API、開発環境

GET https://api.weatherapi.com/v1/current.json?q=Beijing

ボーナス: デバッグの苦痛から解放？EchoAPI を試してみよう

トークン、ヘッダー、複雑な署名に頭を悩ますのはもう厌了吧？ EchoAPI なら、API をデバッグするのが、500 行の curl スクリプトを書くより、コーヒーを啜るような快適さだ。

実用的な環境で即戦力: GitHub への呼びかけや、社内のレガシーシステムと通信する際も、EchoAPI がサポート
統一テスト環境: Bearer 認証から AWS 署名まで、すべてのテストが 1 つの場所で可能
大企業でも採用済み: NTLM から Akamai EdgeGrid まで、大規模なシステムでも対応
高速デバッグ: ログインシミュレーション、認証フロー、サービスコールの実行が可能。手動のヘッダーコピペの苦痛から解放

暗号化方法についてもっと詳しく知りたい場合は、EchoAPIのブログを検索してみてください。