HTTP認証
HTTPの要求・応答で、サーバが認証方式を示し、クライアントが認証情報を送る仕組み。Basic方式では、利用者名とパスワードを所定の区切り文字で連結し、Base64で表した値を要求に含める。
イマシルちゃんの解説
受付で「ここに入るには、この確かめ方を使ってね」と案内される場面を考えてみよう。
来た人は、その案内に合った形で答えを返すんだ。
文字の書き方を変えるだけの方法と、渡されたお題で計算する方法があるよ。
書き方が読みにくくなっただけで、秘密になったとは限らないんだ。
より深い解説
サーバが方式を案内する
一般的には、保護された資源への要求に対してサーバが401の応答を返し、WWW-Authenticateで方式などを提示する。クライアントは対応するAuthorizationを付けて要求する。
| フィールド | 主な方向と意味 |
|---|---|
| WWW-Authenticate | サーバから、要求する認証方式などを伝える |
| Authorization | クライアントから、方式に応じた値を送る |
アクセス権限があるかの判断は、本人確認とは別の処理である。認証に成功しても、すべての資源を利用できるとは限らない。
Basic方式の表現
RFC 7617で定義される方式である。利用者名とパスワードの間にコロンを入れ、全体をBase64へ変換する。独自の例として、名前がdemo、パスワードがsampleなら、変換前はdemo:sampleとなる。
Authorization: Basic （変換した文字列）この変換は暗号化ではなく、元の文字列へ戻せる。通信内容が見える経路では秘密が漏れるため、HTTPSなどで通信路を保護する必要がある。
Digest方式の考え方
Digest方式はRFC 7616で定義される。サーバが示したnonceや、利用者の秘密に基づく値、要求のメソッド・URIなどを使い、応答値を計算する。
単に「利用者名:パスワード」をハッシュ化した値を送る方式ではない。要求の情報やサーバから与えられる値を組み込む点が、Basic方式と異なる。
| 観点 | Basic | Digest |
|---|---|---|
| パスワードの扱い | 可逆な表現に含まれる | それ自体を直接は送らない |
| サーバが与える値 | 応答計算の材料には使わない | 計算へ組み込む |
| 古い応答の再利用への備え | 方式単独では不十分 | nonceやカウンタなどを利用する |
採用するアルゴリズムや設定を確認する必要がある。古い方式名だけで安全性を判断せず、通信路の保護とパスワードの強さも考慮する。
通信路やアプリケーション認証との分担
認証方式を使っても、それだけでページ本文まで暗号化されるわけではない。また、プロキシによる認証では、通常のサーバ認証と異なる407応答などを使う。