基本認証とベアラートークン どのAPI認証方法を使うか

すべてのAPIリクエストは、誰がリクエストを行っているかを証明しなければなりません。選択する方法は、あなたのセキュリティポジション、開発者体験、および運用負荷を長期間にわたって決定します。基本認証、APIキー、ベアラートークン、OAuthはそれぞれ異なる問題を解決しており、間違った方法を選ぶと、後で解消するのが非常に困難な負債が生じます。以下に、それぞれの方法についての明確な解説、コピー可能なコード、および判断表を提供し、あなたの使用ケースに最適な方法を選択できます。

HTTP基本認証

基本認証は、すべてのリクエストに認証情報を送信します。クライアントはユーザー名とパスワードを組み合わせ、 username:password、Base64でエンコードし、 Authorization ヘッダーに配置します：

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

このBase64文字列は 暗号化されていませんです。リクエストをキャプチャした誰もが数秒でこれをデコードできます。基本認証はHTTPSでのみ安全であり、それであっても、認証情報はすべてのリクエストに含まれ、サーバーログに残る場合があります。積極的にそれらを削除しない限りです。

認証情報を手動でエンコードせずに正しいヘッダー値を生成するには、 IO Tools 基本認証ジェネレーターを使用します.

# curl with Basic Auth
curl -u username:password https://api.example.com/data

# Or with the explicit header
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

// fetch with Basic Auth
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
  headers: { Authorization: `Basic ${credentials}` }
});

使用が許容される場合： 内部ツール、開発環境、および両端を制御できるサーバー間の統合において。公開APIやユーザー対応認証には絶対に使用しない。

APIキー

APIキーは、静的トークンであり、特定のアプリケーションまたは呼び出し者に紐づけられた長いランダムな文字列です。クライアントは通常、 X-API-Key または Authorization ヘッダーにカスタムスキームで送信します：

# curl with API key
curl -H "X-API-Key: sk_live_abc123xyz" https://api.example.com/data

# Or with Authorization header
curl -H "Authorization: ApiKey sk_live_abc123xyz" https://api.example.com/data

// fetch with API key
fetch('https://api.example.com/data', {
  headers: { 'X-API-Key': 'sk_live_abc123xyz' }
});

APIキーは実装が簡単で、侵害された場合にすぐに削除できます。ただし、状態を持たず、期限付きの機能がありません。キーが漏洩すると、手動で削除するまで有効です。署名や埋め込みスコープがなく、データベースに検索するだけの文字列です。

使用する場合： 第三者統合、開発者向けAPI製品、公開APIアクセスにおいて、クライアントごとのレート制限と即時削除を必要とする場合。

ベアラートークン（JWT）

ベアラートークン——最も一般的にJWT（JSON Web Token）——は、認証サーバーによって発行され、 Authorization ヘッダーに Bearer スキームで送信されます：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

JWTは署名されたペイロードを含み、ユーザーの識別、権限、および有効期限を含みます。サーバーは署名を共有秘密または公開鍵で検証することで、データベースの検索を必要とせず、トークンを検証します。この状態なしの検証は、分散システムやマイクロサービスアーキテクチャにおいて大きな利点です。

その代償は現実です：JWTは大きいため（1リクエストあたり数百バイト）、有効期限前に無効化するには追加インフラ（トークンブローカー）が必要です。実装ミス——弱い署名秘密、有効期限チェックの欠如、アルゴリズムの混乱攻撃——は、生産環境での重大なセキュリティ侵害を引き起こしました。

# curl with Bearer token
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  https://api.example.com/data

// fetch with Bearer token
fetch('https://api.example.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

使用する場合： ユーザー対応API、マイクロサービスが識別を下流に伝達する場合、短命の認証情報と埋め込みの主張がサーバー側のセッション状態を減らす場合。

OAuth 2.0：アクセストークンとリフレッシュトークン

OAuth 2.0はトークン形式ではありません。それはデリゲーションプロトコルです。アプリケーションがユーザーの代わりに別のサービスのリソースにアクセスする必要がある場合、OAuth 2.0は承認とトークン交換を処理します。

簡潔なフロー：ユーザーがアクセスを承認し、認証サーバーが短命の アクセストークン と長命の リフレッシュトークンを発行し、アプリはアクセストークンを使用してAPI呼び出しを行い、アクセストークンが期限切れになると、リフレッシュトークンで新しいトークンを交換し、ユーザーに再び確認を要求しません。

# Step 1: Exchange credentials for a token (client credentials flow)
curl -X POST https://auth.example.com/token \
  -d "grant_type=client_credentials" \
  -d "client_id=myapp" \
  -d "client_secret=mysecret"

# Step 2: Use the access token
curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.example.com/data

# Step 3: Refresh when expired
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=REFRESH_TOKEN" \
  -d "client_id=myapp"

アクセストークンは通常JWTです。リフレッシュトークンはオパクな文字列であり、サーバー側に保存します——ブラウザ側コードに絶対に暴露しないでください。

必要になる場合： SNSログイン、第三者データアクセス、どの「ログインでX」統合、または人間ユーザーがアプリケーションがそのユーザーの代わりに何を実行できるかを承認する必要がある場合。

すべての方法に適用されるセキュリティルール

選択する認証方法に関わらず、以下のルールは例外なく適用されます。

• HTTPS everywhere。 HTTPで認証情報やトークンを送信すると、誰もパケットを検査できる瞬間、セキュリティが破綻します。例外はありません。
• コードにシークレットを保存しない。 環境変数またはシークレットマネージャーを使用してください。コード管理ファイルにシークレットを保存しない——特に .gitignore、なぜならその除外は実際には信頼できません。
• スケジュールや疑いに基づいて回転する。 APIキーはダウンタイムなしで回転できるようにし、JWTの署名シークレットはバージョン化をサポートして、すべてのアクティブセッションを一度に無効化せずに回転できるようにします。
• 機能する最短期間。 アクセストークン：分間から数時間。APIキー：人員変更時に回転。基本認証情報：特別権限と積極的に回転する。
• 誰が何を持っているかを監視する。 発行された認証情報を登録してください。何かが間違った場合、何が発行されたか、誰に、いつの間にか知る必要があります。

判断ガイド：どの方法がどの使用ケースに適するか

方法	状態なし	削除可能	複雑	最適な用途
Basic認証	はい	認証情報の変更のみで	非常に低い	内部ツール、開発環境
APIキー	はい	は、即時	低い	第三者統合、開発者API
ベアラー（JWT）	はい	トークンブローカーのみで	中くらい	ユーザー対応API、マイクロサービス
OAuth 2.0	変動	はい	高い	ユーザーのデリゲーション、第三者認証

内部API、サーバー間、ユーザーなし： APIキー。実装が簡単で、即時削除可能で、容易に監視できます。すでにマイクロサービスでJWTを使用している場合は、短命のサービスアカウントトークンを使用します。

外部開発者消費者向けの公開API： APIキーにキーごとのレート制限とセルフサービス管理ポータルを加え、消費者が自らのユーザーのリソースにアクセスを要求する場合、OAuthスコープを追加します。

自社製品のユーザー対応認証： 短命のJWTとリフレッシュトークンの回転。認証の検証後にトークンを発行し、短命に保ち、XSSリスクがあるアプリケーションでは localStorage に保存しないでください。

ユーザーの代わりに第三者サービスにアクセスする場合： OAuth 2.0の認可コードフローを使用します。これは短絡化しないでください。ユーザーのデリゲーションモデルは、スケールで第三者の承認を安全に処理するための最も安全な方法であるからです。

正しい選択は、2つの質問に帰着します：呼び出し者は誰か、そして人間ユーザーが呼び出し者の行動に承認する必要があるか？呼び出し者がマシンであり、ユーザーのデリゲーションが関与していない場合、APIキーがほとんどのケースをクリーンに処理します。埋め込みの主張や状態なしの跨サービス識別が必要な場合はJWTを追加し、ユーザーの承認がフローに含まれる場合はOAuthに依頼します。

あなたも好きかもしれません