「HTTP」の仕組みをおさらいしよう（その4）：リトライ！ 触って学ぶTCP/IP（5）（2/2 ページ）

TCP/IPの仕組みを、専用ツールを使って学習していく本連載。第5回では「認証」の仕組みについて、実際のリクエスト／レスポンスを確認しながら学びます。

[福永勇二（インタラクティブリサーチ），＠IT]

認証の仕組みを実際に確認してみよう！

　では、プロトコルビュワーを使って、Basic認証が設定されたページにアクセスしてみましょう。この実験のために用意したURL「http://ait-sample.list.jp/rtcp/p05-auth/index.html」には、Basic認証が設定されています。通常のブラウザでここにアクセスすると、ユーザー名とパスワードの入力を求められますので、これにユーザー名「aituser」とパスワード「12345@abcde」を指定してみてください。すると認証をパスして、「認証に成功しました！」と大きな文字が表示されるはずです。

図5　認証をパスしたときの表示

（1）認証情報を付加せずに、認証が必要なページにアクセスする

　まずは、認証がないと想定して、プロトコルビュワーで上記のURLにアクセスしてみましょう。このときのリクエストは、図6に示すような、Authorizationヘッダがないごく一般的なGETリクエストにして送信します。

図6　ごく一般的なGETリクエスト

　さて、どのようなレスポンスが返ってきましたか？ 図7のようにステータスコード401が返されたはずです。そしてWWW-Authenticateヘッダには、要求される認証の種類と保護空間名がセットされます。またメッセージ本体には、人間に読める形で認証が必要なことの説明などが入ります。

図7　ステータスコード401のレスポンスが返ってくる

図8　実験をしているプロトコルビュワーの様子

　通常のブラウザでは、このレスポンスを受信したとき、ユーザー名とパスワードを入力するダイアログを開き、それらの値をユーザーに入力させます。そして、その2つの値をコロンを挟んでつなぎ、Base64変換することにより、認証情報を生成することになります。

　このBase64変換を行う方法にはいろいろな種類があるのですが、プロトコルビュワーで実験をするときに簡単に利用できるよう、本連載独自のBase64変換ツールを用意しました。下記のリンクをクリックすると、別ウィンドウまたは別タブが開き「Base64変換器」が現れますので、その画面で、「平文→Base64形式」「Base64形式→平文」の変換を行ってみてください。

参考リンク：Base64変換器

図9　Base64変換器の画面

　なお、この変換器での変換処理は全てブラウザ内で完結しており、変換前後の情報が外部サーバに送られることは一切ありません。また、Internet Explorerで「ブロックされているコンテンツを許可」ボタンが表示されたときは、それをクリックしてください。

（2）認証情報を付加して、認証が必要なページにアクセスする

　次に、認証情報を付加したリクエストを作り、同じURLに再びアクセスしてみましょう。図10に認証情報付きのリクエストを示します。先ほどのリクエストとの違いは、Authorizationヘッダが加わったことです。

図10　認証情報を加えたGETリクエスト

　このリクエストに対するレスポンスはどうでしょうか？ 恐らく図11のように、ステータスコードは200の正常終了になり、本来取得すべき内容が、メッセージ本体に取得できているはずです。

図11　ステータスコード200のレスポンスが得られる

　これら2つの実験から、HTTPのレベルにおいては、ステータスコード401が返るかどうかで認証の有無を判定し、認証が設定されたURLについては、Authorizationヘッダに認証情報を与えることで認証をパスし、内容にアクセスできることが分かったはずです。

　なお実際のブラウザでは、一度認証に成功した後は、ブラウザを終了させるまでの間、保護空間名とそれに対応する認証情報を内部に保存しておきます。そして、同じ保護空間名を持つページにアクセスするときには、保存されている認証情報を使い回すことにより、ユーザー名とパスワードの入力を省略します。

　また、「1つの保護空間は同ディレクトリ内のファイルや子ディレクトリに及ぶ」という性質を利用して、あるページの認証に成功した際、同ディレクトリ内のファイルや子ディレクトリへのアクセス時にも、最初から認証情報を含むAuthorizationヘッダを付けるなどして、なるべくWebサーバとのやりとりを減らす工夫もなされています。