Webを支える技術第9章 HTTPヘッダその3

HTTP ヘッダの続きです。

認証
- Basic 認証と Digest 認証
- サーバは HTTP ステータスコード 401 Unauthorized と WWW-Authenticate ヘッダで認証が必要なことと認証方式を伝える
- realm には URI空間の名前 - URI 内のあるパス以下を総称する名前
- Basic 認証
  - Authorization ヘッダに認証情報("Basic " + ユーザ名とパスワードを":" で連結して Base64 エンコードしたもの)を入れてリクエストする
  - パスワードが平文で渡されるので HTTPS(SSL や TLS を使った通信路の暗号化)を使って通信しないと簡単に漏洩する
- Digest 認証
  - 最初の認証情報なしのリクエスト(チャレンジ)に 401 Unauthorized と WWW-Authenticate ヘッダに realm(URI空間名)のほかに以下の情報が入る
    - nonce - 1回かぎりの使い捨てのトークン
    - qop (quality of protection) - auth または auth-init
      - auth はURIとメソッドだけからダイジェストを作成する
      - auth-init はメッセージボディもダイジェストの元に含める
    - opaque - クライアントには推測できない文字列
  - (1) クライアントはユーザ名、realm、パスワードを ":" で連結して MD5 ハッシュ値を求める
  - (2) メソッドとURIを ":" で連結して MD5 ハッシュ値を求める
  - (3) (1) + サーバが返した nonce + クライアントがnonceを返した回数(00000001) + クライアントが生成した nonce + qop + (2) を全て ":" で連結して MD5 ハッシュ値を求めてそれを response フィールドに入れた Authorization ヘッダを含むリクエストを投げる (クライアント生成 nonce (cnonce) と nonce を返した回数(nc)もそのヘッダのフィールドに入れる
  - Digest 認証はパスワードそのものは認証時には送信しない、サーバ側で平文パスワードを保存しなくていい(ハッシュ値だけ持っておけばいい)など Basic 認証に比べてメリットがある
  - リクエストするたびにチャレンジを送信してレスポンスを受け取ってからハッシュ値を求めて送り返さないといけない
- WSSE認証 (WS-Security Extention)
  - HTTP 1.1 標準ではない認証方式
  - チャレンジのレスポンスの WWW-Authenticateヘッダに WSSE 方式の指定と realm, profile が含まれる
  - profile の値は現状 "UsernameToken" のみ
  - パスワード + nonce + 日時を連結して SHA-1 ハッシュ値を求めて Base64 エンコーディングする(パスワードダイジェスト)
  - Authorization ヘッダには WSSE profile="UsernameToken" を入れる
  - X-WSSE 拡張ヘッダに Username, PasswordDigest, Nonce, Created(日時) を入れてリクエスト
  - WSSE はパスワードを平文で送らなくてもよいがサーバ側でパスワードの平文を保存しておかないといけない
- コラムより。WEBサービス間で認証/認可を行うための仕様 OpenID と OAuth
キャッシュ
- サーバは Pragma ヘッダによってそのリソースがキャッシュ可能でないことを指定できる
- Expires ヘッダでキャッシュの有効期限はいつまでかを指定できる
- Cache-Control ヘッダでより細かい制御ができる
- 条件つきGET
  - If-Modified-Since ヘッダに日時を入れてリクエストすると、その日時以降更新がなければ 304 Not Modified を返す
  - If-None-Match ヘッダで ETag を入れると ETag が更新されていなければ 304 Not Modified を返す。 ETag の値は ETag ヘッダで返される