ここから本文です

知ってるつもり?:「HTTP」の仕組みをおさらい

@IT 8月11日(木)8時10分配信

 TCP/IPの仕組みについて、“目で見て触って”学ぶ本連載。第5回では、「認証」の仕組みを見ていきます。プロトコルビュワー(※)での実行結果とブラウザの動作を見比べながら、HTTPへの理解をさらに深めましょう。

【その他の画像】ブラウザの認証動作とHTTPリクエストのフローチャート

※「プロトコルビュワー」
 本連載では、筆者が作成した「プロトコルビュワー」というツールを使い、実際のリクエスト/レスポンスの内容を見ながら学習を進めていきます。


●認証とは?――実際のアクセスの流れ

 認証とは、「Webへのアクセスに際してユーザー名とパスワードを求め、それらがあらかじめ登録してあるものと合致したときだけ、リクエストされた内容を送り返す仕組み」のことです。認証を利用することで、ユーザー名とパスワードを知っている人だけが特定のWebサイトなどにアクセス可能になり、情報を保護することができます。

 Webでの認証にはHTTPの2つのヘッダが大きな役割を果たしています。1つは「WWW-Authenticate」ヘッダで、サーバからクライアントに向けて「サーバが要求する認証の種類」を知らせる働きがあります。もう1つは「Authorization」ヘッダで、クライアントからサーバに向けて、「認証のためのユーザー名とパスワード」を知らせる働きがあります。

 では、2つのヘッダの存在を知ったところで、認証が必要なページにアクセスしたときブラウザがどんな動作をするのかを見てみましょう。図3は、認証が必要なページにアクセスしたときの、一般的なブラウザの動作イメージを示したものです。


1. URLを入力またはリンクをクリックすると、ブラウザはWebサーバに対してHTTPリクエストを送る。リクエストの対象に認証が設定されていなければ、Webサーバはステータスコード200とリクエストした内容を返す

2. リクエストした対象に認証が設定されている場合、Webサーバは、ステータスコード401で認証が必要なことを知らせ、WWW-Authenticateヘッダでサーバが要求する認証の種類を通知する

3. これを検出したブラウザは、画面にダイアログを表示して、ユーザー名とパスワードを入力するようユーザーに求める

4. ブラウザは、入力されたユーザー名とパスワードから認証情報を生成し、それをリクエスト中のAuthorizationヘッダにセットして、再度WebサーバにHTTPリクエストを送る

5. ユーザー名とパスワードが正しければ、Webサーバはステータスコード200とリクエストした内容を返す。これで認証が設定されている情報を読み出せたことになるので、ブラウザはその内容を表示する

6. 入力したユーザー名あるいはパスワードが間違っている場合は、Webサーバは再びステータスコード401とWWW-Authenticateヘッダを返す。これを検出したブラウザは、再びユーザー名とパスワードの入力を求め、以下、同様の動作を繰り返す

 このように、「ブラウザはまず認証がないことを想定してWebサーバへアクセスし、Webサーバが認証を要求したら、利用者にユーザー名とパスワードを入力させて、その情報をAuthorizationヘッダに添えて再度Webサーバにアクセスする」という動作をします。このとき、ユーザー名とパスワードの両方が合っているときにのみ、リクエストした内容がサーバから送り返されてきます。

●Basic認証の概要

 HTTPで利用できる認証方法(認証スキーム)のうち、恐らく最も広く利用されているのが「Basic認証」です。ここでは、Basic認証について説明します。ちなみに、Basic認証以外のものとしては、「ダイジェスト認証」(パスワードを送らないのでより安全)などがあります。

 Basic認証では、Authorizationヘッダに、「Basic」の文字と、その後に1つ空白を挟んで、ユーザー名とパスワードから生成した認証情報を指定します。この認証情報は、「ユーザー名:パスワード」の形で、ユーザー名とパスワードをコロン(:)でつなぎ、それ全体をBase64と呼ばれる方式で変換して作成します。

 変換例を示します。ユーザー名が「aituser」、パスワードが「12345@abcde」のとき、両者をコロンでつないだ「aituser:12345@abcde」をBase64変換すると「YWl0dXNlcjoxMjM0NUBhYmNkZQ==」が得られます。これをAuthorizationヘッダに指定します。

 このBase64変換は一見暗号化のように見えますが、逆変換も簡単に行えるもので、暗号化の効果は全くありません。単純に、表現の形式を変換しているだけです。そのため、Basic認証をそのまま単体で使うと、誰でも読める状態でユーザー名とパスワードがインターネットを流れてしまうことには注意が必要です。もし、高い機密性が必要であれば、HTTPの通信路を暗号化する「HTTPS」と組み合わせることを検討しましょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[福永勇二(インタラクティブリサーチ),@IT]

最終更新:8月11日(木)8時10分

@IT