Web API（Application Programming Interface）は、インターネット経由でデータや機能をやり取りするための基盤です。
しかし、適切なセキュリティ対策を行わずにエンドポイント（URL）を公開してしまうと、悪意のある第三者を含む誰からでもリクエストを実行されてしまいます。
そのため、リクエストを受け取る入口で「誰がアクセスしているのか」「その操作を実行する権限があるのか」を厳密にチェックする仕組みが不可欠です。
本記事では、Web APIにおける主要な4つの認証・認可方式（Basic認証・APIキー・JWT・OAuth 2.0）の内部構造やメリット・注意点、さらに混同しやすい「認証」と「認可」の違いについて分かりやすく解説します。
認証と認可の決定的な違い
WebセキュリティやAPI設計の現場において、「認証（Authentication）」と「認可（Authorization）」は頻繁に混同されますが、その役割は明確に異なります。
-
認証（Authentication / AuthN）：【あなたは誰か？】
通信相手の「身元」を確認・特定するプロセスです。IDとパスワードの照合、指紋や顔認証、SMSによる二要素認証などが該当します。日常例で言えば「パスポートや身分証明書の提示」にあたります。 -
認可（Authorization / AuthZ）：【あなたは何をしてよいか？】
特定されたユーザーやクライアントに対して、「何のリソースへのアクセスを許可するか」「どの操作（読み取り・編集・削除など）を実行してよいか」という権限を与えるプロセスです。日常例で言えば「コンサートの入場チケットや関係者専用パス」にあたります。
| 比較項目 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| 問いかけ | あなたは誰ですか？（Identity） | あなたは何ができますか？（Permissions） |
| Webでの具体例 | ユーザー名とパスワードによるログイン | 管理者専用ページの表示、特定データの編集権限判定 |
| 実行順序 | 最初に行われる（前提条件） | 認証の完了後に行われる |
APIの保護においては、まず「認証」によってリクエスト送信者を特定し、その上で「認可」によって該当APIの実行権限をチェックするという二段階の防御が基本となります。
Basic認証（基本認証）の仕組みと特徴
Basic認証は、HTTPプロトコルの標準仕様（RFC 7617）として古くから定義されている最もシンプルな認証方式です。
Basic認証のリクエスト手順
- ユーザー名とパスワードをコロンで連結します（例：
username:password）。 - 文字列全体をBase64形式にエンコードします。
- HTTPリクエストの
AuthorizationヘッダーにBasic <Base64文字列>として付与して送信します。
GET /api/v1/user/profile HTTP/1.1
Host: api.example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=Base64エンコードに関する重要な注意点
Basic認証を扱う上で絶対に誤解してはならないのが、「Base64は暗号化ではなく、単なる文字変換（エンコード）である」という点です。
Base64は、バイナリや多言語テキストを英数字記号の64文字（A-Z, a-z, 0-9, +, /）で表現するためのデータ変換ルールです。暗号鍵を使用しないため、Base64文字列を入手すれば誰でも一瞬で元のユーザー名とパスワードに復号（デコード）できます。
平文のHTTP通信上でBasic認証を使用すると、ネットワーク盗聴によってパスワードがそのまま漏洩します。そのため、Basic認証を利用する際は常時HTTPS（TLS暗号化）による通信路の保護が必須要件となります。
APIキー認証の仕組みと活用シーン
APIキー認証は、APIプロバイダーが発行した一意のランダムな文字列（API Keyやトークン）を、リクエストヘッダーやクエリパラメータに付与して通信を行う方式です。
GET /api/v1/weather?city=Tokyo HTTP/1.1
Host: api.example.com
X-API-KEY: ak_live_9f83a2bc710d4821e9a3b8c4d12APIキー認証が選ばれる理由とメリット
- 導入と実装の手軽さ：サーバー側は受け取ったキーがデータベースに登録されている有効なものか照合するだけであり、クライアント側もヘッダーに固定文字列を添えるだけです。
- 利用状況の追跡と従量課金：APIキーごとに「誰が」「いつ」「どれだけ」リクエストを送信したかを正確に測定できるため、SaaSのプラン別課金や従量課金システムの構築に最適です。
- レートリミット（リクエスト流量制限）：過剰な負荷やDDoS攻撃を防ぐため、「1分間に100回まで」といった制限をユーザー・システム単位で制御できます。
APIキー運用のリスクと失効管理
APIキーの実質的な性質は固定パスワードと同じです。ソースコードやGitHubなどの公開リポジトリに誤ってコミットしてしまった場合、第三者に勝手にAPIを利用されて高額請求が発生するリスクがあります。
そのため、万が一漏洩した場合には速やかにキーを失効（Revoke）させ、新しいキーを再発行できる管理インターフェースを用意しておくことが極めて重要です。
JWT（JSON Web Token）によるステートレス認証
JWT（ジョット / JSON Web Token）は、JSONフォーマットの情報を安全に転送するためのオープンスタンダード規格（RFC 7519）です。モダンなWebサービスやシングルページアプリケーション（SPA）、マイクロサービスアーキテクチャで広く採用されています。
JWTを構成する3つの要素
JWTはドット（.）で区切られた3つのBase64URL文字列で構成されています。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MjM2OTkyMDB9.4PaoK8z6Fm1V4...| 構成要素 | 内容 | 役割 |
|---|---|---|
| ヘッダー（Header） | トークンの種別（JWT）や使用する署名アルゴリズム（HS256, RS256等） | 検証方法の指定 |
| ペイロード（Payload） | ユーザーID、権限（Role）、有効期限（exp）などのクレーム情報 | 伝達したい実データ |
| 署名（Signature） | ヘッダー＋ペイロード＋サーバーの秘密鍵から計算されたハッシュ値 | データの改ざん検知 |
署名による改ざん検知とステートレス設計の強み
なぜ改ざんできないのか？
クライアント側で勝手にペイロードの権限を「一般ユーザー」から「管理者（admin）」に書き換えたとしても、サーバー側で保持する秘密鍵がない限り、正しい署名（Signature）を再計算できません。サーバーがトークンを検証した時点で不整合が即座に検知され、リクエストは拒絶されます。
ステートレス（Session-less）による優れた拡張性
サーバー側はセッション情報をデータベースやメモリ（Redis等）に保存しておく必要がありません。受け取ったJWTの署名検証を行うだけでユーザー情報や権限を特定できるため、サーバー台数を増やす水平スケーリング（負荷分散）が極めて容易になります。
OAuth 2.0 による安全な権限委譲
OAuth 2.0は、現在のWebサービスにおいて最も広く利用されている認可フレームワーク（RFC 6749）です。
「Googleアカウントでログイン」「GitHubでサインイン」といったソーシャルログイン機能や、外部アプリがユーザーのGoogleカレンダーやDriveにアクセスする連携機能の裏側には、このOAuth 2.0が使われています。
パスワードを渡さずに権限だけを委託する仕組み
従来の方式では、外部アプリに機能連携を許可するためにユーザーがIDとパスワードをアプリ側に教える必要があり、セキュリティ上の深刻なリスクとなっていました。
OAuth 2.0では、ユーザーは信頼できる認可サーバー（GoogleやGitHubなど）で直接認証を行い、認可サーバーからアプリに対して期間限定の「アクセストークン（Access Token）」を発行します。
OAuth 2.0がもたらす高い安全性
- パスワード非保持：外部アプリ側はユーザーのログインパスワードを一切知り得ません。
- スコープ（Scope）による最小権限の付与：「連絡先の閲覧のみ許可し、メール送信は許可しない」といった細かな権限範囲の限定が可能です。
- いつでも失効可能：ユーザーはGoogle等の管理画面から、いつでも特定アプリへの連携解除（トークン失効）を実行できます。
主要な4方式の比較と選定基準
各方式にはそれぞれ適したユースケースと特性があります。要件に応じて最適な方式を選択しましょう。
| 方式名 | セキュリティ強度 | 実装難易度 | 主な適用ユースケース |
|---|---|---|---|
| Basic認証 | 低〜中（HTTPS必須） | 極めて容易 | 開発環境・ステージングの一時的な閲覧制限、簡易内部API |
| APIキー認証 | 中（キー管理重要） | 容易 | 公開Web API、BtoBシステム間連携、従量課金SaaS |
| JWT認証 | 高（改ざん検知） | 中 | SPA・モバイルアプリとバックエンドAPI間のセッションレス通信 |
| OAuth 2.0 | 極めて高 | 高 | ソーシャルログイン、サードパーティアプリ連携、権限委託 |
まとめ
Web APIの認証・認可は、システム全体の安全性とユーザー体験を左右する重要なアーキテクチャ設計です。
- 「認証（Identity）」と「認可（Permission）」の役割分担を明確にする。
- 簡易な連携や利用量制限にはAPIキーを活用する。
- スケーラビリティを重視するモダンAPIには改ざん防止機能を持つJWTを採用する。
- 第三者連携や安全な権限委託にはOAuth 2.0を導入する。
システムの規模や取り扱うデータの重要度に合わせて適切な認証方式を選択し、堅牢でスケーラブルなWeb APIを構築していきましょう。
