鍵を渡すか、身分証を見せるか。Web通信における「認証」の仕組みを紐解く
Webサイトにアクセスしたとき、突然現れる「IDとパスワードを入力してください」という小さなウィンドウ。あれ、一体裏側では何が行われているのでしょうか？
今日は、ネットワークの入り口に立つ皆さんと一緒に、HTTP/1.1で標準的に使われてきた「Basic認証」と「Digest認証」の仕組みを覗いてみようと思います。難しいパケットの話は一旦置いておいて、まずは身近な例えから入っていきましょう。
—
1. Basic認証：一番シンプルな「鍵の渡し方」
Basic認証は、いわば「合鍵を封筒に入れて渡す」ような仕組みです。
あなたが友人の家を訪ねる際、ドアを開けるたびに「合鍵」を渡す状況を想像してみてください。HTTPの世界では、ブラウザがサーバーに対して「これが私のIDとパスワードです！」と、毎回通信のたびに名乗りを上げます。
仕組みは「Base64」という包装紙
ここで一つ重要なのは、パスワードがそのまま平文で送られているわけではないという点です。といっても、暗号化されているわけではありません。「Base64」という、「見た目を少し変える（エンコードする）」という処理を施しているだけなんです。
例えば、IDが`admin`、パスワードが`password123`だとしましょう。これを合体させてBase64で変換すると、こんな文字列になります。
// 実際にはこんな文字列がヘッダーに乗ります
Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=
「なんだか暗号っぽくてカッコいい！」と思うかもしれませんが、これは誰でも簡単に元のIDとパスワードに戻せてしまう（デコードできてしまう）ものです。例えるなら、中身が透けて見える透明な封筒に鍵を入れて送っているようなもの。だからこそ、Basic認証を使うときは、通信全体を暗号化する「HTTPS（SSL/TLS）」が必須なんですね。
—
2. Digest認証：賢い「身分証の提示」
Basic認証の弱点である「パスワードをそのまま送るリスク」を解決するために生まれたのが、Digest（ダイジェスト）認証です。
これは「パスワードそのもの」を渡す代わりに、「パスワードを知っている人なら、これと同じ計算結果を出せるはずだよね？」というクイズ形式で本人確認を行います。
郵便配達に例えるとこうなります
1. サーバー（郵便局）からのお題: 「今の時刻と、私の用意したランダムな数字（ナンスと言います）を混ぜて、パスワードで計算して回答を送って！」
2. クライアント（あなた）の回答: 計算結果（ハッシュ値）だけを返送。
3. サーバーの確認: サーバー側も同じ計算をして、答えが合っていれば「はい、どうぞ！」
ここが賢いポイントです。通信経路を誰かが盗聴していても、渡しているのは計算結果だけなので、本当のパスワードは決してバレないのです。
—
3. 現場で役立つ確認ポイント
もし皆さんが開発中に「認証がうまくいかない！」というトラブルに直面したら、ブラウザの「開発者ツール（F12キー）」を開いて、以下の項目をチェックしてみてください。
ブラウザの「ネットワーク」タブを見てみよう
通信をクリックして「ヘッダー」を確認すると、以下のようなやり取りが見えるはずです。
- Request Headers: ここに `Authorization` ヘッダーが含まれているか？
- Response Headers: サーバーから `WWW-Authenticate` という「認証してね！」というメッセージが返ってきているか？
もしDigest認証を使っているなら、サーバーからの応答ヘッダーの中に `nonce=”…”` という長いランダムな文字列が含まれているはずです。これが認証の鍵になるんですよ。
—
一歩ずつ、確実に理解していきましょう
最初は「Base64？」「ハッシュ？」「ナンス？」と聞き慣れない言葉に戸惑うかもしれません。でも、ネットワーク技術の本質は、実はとても人間味のある「やり取り」のルールなんです。
- Basic認証：手軽だけど、封筒が透けていないか（HTTPS）注意が必要。
- Digest認証：少し手間はかかるけど、答えだけを渡すので安全。
この2つの違いを理解しておくだけで、皆さんのインフラに対する解像度はぐっと上がります。「パケットは郵便物である」という視点を忘れずに、これからも一つずつ紐解いていきましょうね。
次は、実際にこのヘッダーを自分で書き換えて通信を試す実験をしてみるのも面白いかもしれませんよ！
コメント