なぜ今さら「Basic/Digest認証」なのか？：HTTPヘッダーの深淵を覗く
現場でトラフィックを追いかけていると、最新のJWT（JSON Web Token）やOAuth 2.0の複雑なフローに目を奪われがちですが、インフラの基礎体力として避けて通れないのが、HTTP/1.1で標準化された「認証ヘッダー」の挙動です。
「Basic認証なんて古臭いし、Base64で送るだけだろ？」と高を括っていると、いざ本番環境でプロキシに食われたり、HTTPS化を忘れて認証情報を平文で晒したりする事故に直結します。今回は、RFC 7617（Basic）やRFC 7616（Digest）の仕様をなぞるのではなく、パケットレベルで何が起きているのか、エンジニアの視点で紐解いていきましょう。
—
401 Unauthorizedの「本当の役割」
多くの初心者が誤解していますが、`401 Unauthorized` は「アクセス拒否」ではありません。「認証情報が足りていないので、この形式で再送してほしい」という、サーバーからの丁重なリクエストです。
1. クライアント: 認証情報なしでリクエストを投げる。
2. サーバー: 「誰だかわからないから、これを返せ」と `401` を返す。この時、必ず `WWW-Authenticate` ヘッダーを含めるのがマナーです。
3. クライアント: サーバーが要求した認証方式（BasicやDigest）を解釈し、認証情報を付与して再送する。
この「2往復」のハンドシェイクを理解していないと、アプリケーションのレイテンシ設計で確実に躓きます。
—
Basic認証：実装のシンプルさとリスクの表裏
Basic認証は、`Authorization` ヘッダーに `Basic
Pythonでのリクエスト例
import requests
from requests.auth import HTTPBasicAuth
認証情報をセット。HTTPSは必須です。平文で流れたら即アウトと心得る。
url = “https://api.example.com/v1/resource”
response = requests.get(url, auth=HTTPBasicAuth(‘username’, ‘password’))
ヘッダーを確認すると ‘Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=’ となる
print(response.request.headers[‘Authorization’])
シニアからのTips:
Base64は暗号化ではありません。単なるエンコードです。もしHTTPS終端をロードバランサーで行う場合、バックエンドへの通信も暗号化されているか必ず確認してください。「LBまではHTTPSだけど、その先はHTTP」という構成でBasic認証を使うのは、セキュリティ要件としては自殺行為です。
—
Digest認証：MD5の影と現代の立ち位置
Basic認証の「平文流出」を補うために作られたのがDigest認証です。パスワードそのものを送るのではなく、`nonce`（使い捨てのランダム文字列）とハッシュ値を用いて認証します。
Digest認証の通信シーケンス（簡略版）
1. Server: `WWW-Authenticate: Digest realm=”…”, nonce=”abc123xyz…”, algorithm=SHA-256`
2. Client: サーバーから貰った `nonce` を使い、`password` を含めたハッシュ値を計算して `Authorization` ヘッダーに含める。
Digest認証は、RFC 7616でSHA-256などのより強固なアルゴリズムが推奨されていますが、実装の複雑さとクライアント側の対応状況から、Web APIの世界では「OAuth 2.0に移行するまでの繋ぎ」という位置づけが現実的です。
—
デバッグで詰まらないための「鉄則」
現場で「なぜか認証が通らない」というトラブルの9割は、以下のいずれかです。
1. Proxyの介入: 透過プロキシやWAFが `Authorization` ヘッダーを剥ぎ取っていないか？（`Proxy-Authorization` を使うべき場面ではないか？）
2. ヘッダーの正規化: 一部のライブラリは、Basic認証ヘッダーのスペースや大文字小文字を厳格にチェックします。curlで叩いて成功するのにコードで失敗する場合、ヘッダーの自動付与機能が悪さをしていることが多いです。
3. WWW-Authenticateの不備: サーバー側が `realm` を適切に設定していないと、ブラウザの認証ダイアログが表示されないことがあります。
curlで疎通確認する際の鉄板コマンド
まずはブラウザやアプリのコードを疑う前に、生のパケットを制御できる `curl` で叩くのが最短ルートです。
-v でヘッダーのやり取りをすべて可視化する
-u で認証情報を渡すと、curlが自動でBase64エンコードしてくれる
curl -v -u “username:password” https://api.example.com/resource
—
最後に：認証は「信頼の契約」
HTTPの認証ヘッダーは、Webの黎明期から存在する枯れた技術ですが、それゆえに「仕様の抜け穴」を突く攻撃も成熟しています。
もしあなたがAPIを設計する立場なら、Basic/Digest認証だけで全てを完結させようとせず、「通信経路の暗号化（TLS）」と「適切なセッション管理」を組み合わせるのが大前提です。特に、レガシーなシステムを扱う際は、ヘッダーに何が乗っているのかを `tcpdump` や `Wireshark` で一度自分の目で確認してみてください。
パケットの並び順やレスポンスコード一つひとつに、先人たちが苦労して築き上げた「安全な通信のための知恵」が刻まれています。そこを理解しているエンジニアこそが、現場で真に信頼される存在になれるのです。
さて、次は「ステートフルなセッション管理」の話をしましょうか。準備はいいですか？
コメント