【実務・中級編】HTTP/1.1の認証ヘッダー(Authorization: Basic/Digest) – HTTPプロトコル・通信規格実践ガイド

HTTP認証の「正体」を見極める：BasicとDigestの深淵

ネットワークの現場に立つと、たかが「認証」というプロセスが、いかに多くのトラブルを引き起こすか思い知らされます。APIの疎通確認で一番最初に躓くポイントであり、一方で「HTTPSを使っているから大丈夫」と過信して、認証の仕組みをブラックボックス化して放置してしまうエンジニアも少なくありません。

今回は、HTTP/1.1における認証の古典にして基本、`Basic`と`Digest`について、現場の視点から深掘りしてみましょう。

—

Basic認証：その脆弱性と「単純さ」の代償

Basic認証は、1990年代初頭のHTTP/0.9〜1.0時代から続く「最もシンプルで、最も危うい」認証方式です。

仕組みのリアル

Basic認証の正体は、ユーザーIDとパスワードをコロン（`:`）で繋ぎ、それをBase64でエンコードしてヘッダーに載せるだけです。

`Authorization: Basic dXNlcjpwYXNzd29yZA==`

この `dXNlcjpwYXNzd29yZA==` は、デコードすれば誰でも一瞬で `user:password` に戻せます。暗号化ではない。「エンコード」に過ぎないのです。だからこそ、Basic認証はTLS（HTTPS）による通信経路の保護が前提となります。ここを忘れると、通信の盗聴者に対してパスワードを公表しているようなものです。

実装のヒント（curl と Python）

現場でパッと挙動を確認したい時、私はこう書きます。

curlでの実行例：

-u オプションを使えば、curlが自動でBase64エンコードしてくれます
curl -v -u “username:password” https://api.example.com/data

Python (Requests) での実行例：

import requests

Requestsライブラリはauthタプルを渡すだけでBasic認証を処理してくれます
response = requests.get(
‘https://api.example.com/data’,
auth=(‘username’, ‘password’) # 内部でBase64エンコードされたヘッダーが生成されます
)
print(response.status_code)

—

Digest認証：パスワードを送らないという「知恵」

Basic認証の脆弱性を補うために登場したのがDigest認証です。こちらはパスワードそのものではなく、パスワードとnonce（ナンス：使い捨ての乱数）を組み合わせた「ダイジェスト値」をやり取りします。

通信シーケンスの妙

Digest認証は、いきなりパスワードを送るのではなく、以下のようなステップを踏みます。

1. Client -> Server: リクエスト（認証なし）
2. Server -> Client: `401 Unauthorized` を返す（`WWW-Authenticate` ヘッダーに `nonce` を含めて）
3. Client -> Server: クライアント側で `MD5(username:realm:password)` と `nonce` を計算し、ハッシュ化した文字列を送信

この仕組みの肝は、サーバーにパスワードのハッシュ値さえあれば、生のパスワードを保存しなくても照合できる点にあります。

主要なパラメーター

Digest認証の `Authorization` ヘッダーには、非常に多くの情報が含まれます。デバッグ時にここを眺めると、認証が失敗している原因（`nonce`の期限切れや、`realm`の不一致など）が即座にわかります。

realm: 認証領域（どの権限範囲に対する認証か）
nonce: サーバーが発行した一意な文字列（リプレイ攻撃防止用）
qop: Quality of Protection（保護の質。主に`auth`が使われる）
nc: Nonce Count（同じnonceが何回使われたか。リプレイ防止の要）

—

現場のトラブルシューティング：なぜ認証は通らないのか？

シニアとして、若手から「認証が通りません」と相談されたら、まず以下の手順で切り分けます。

1. `WWW-Authenticate` を見ろ

ブラウザの開発者ツールや `curl -v` の出力で、サーバーが何を求めているか確認してください。`401` が返っているなら、必ずレスポンスヘッダーにヒントがあります。

2. nonce の枯渇と期限切れ

Digest認証でよくあるのが、「古いnonceを使い回してエラーになる」ケースです。サーバー側で `nonce` の寿命が短い場合、クライアント側でリクエストを再試行するロジックが必要になります。

3. 文字コードと特殊文字

Base64エンコードをする際、パスワードに特殊文字が含まれていると、環境によってはエンコード結果が変わることがあります。API設計をする際は、パスワードの許容文字セットを明確にしておくのが吉です。

—

まとめ：結局、今は何を使うべきか

現代のWeb API設計において、Basic/Digest認証をそのまま使う機会は減りつつあります。強固なセキュリティを求めるなら、OAuth 2.0 や OpenID Connect といったトークンベースの認証が主流です。

しかし、「なぜその認証が必要なのか」「プロトコルレベルで何が起きているのか」を理解しているかどうかで、トラブル対応のスピードは劇的に変わります。

もしあなたが今日、既存のレガシーなシステムを保守・運用することになったなら、この記事を思い出してください。パケットがヘッダーの中で何を叫んでいるのか。その耳を澄ますことが、優秀なエンジニアへの第一歩です。

それでは、また次回のインフラ深掘りでお会いしましょう。現場からは以上です。