仕様書

構文

[21] credentials は、 auth-scheme のみか、その後に auth-param のリスト (#) または token68 を続けたものです。

[22] auth-scheme の後に続く場合には auth-scheme の後に1文字以上の SP が必要です。

[4] auth-param や token68 の部分は auth-scheme によって異なる構文となります。 どの auth-scheme でも共通して必須である引数はありません。

[24] token68 は既存の認証方式の構文との互換性のためのもので、 新しい認証方式は使うべきではありません (ought to) >>22。

authorization credentials

[14] 次のヘッダーは、 authorization credentials に分類されています >>13。

[15] X-WSSE: もこの分類に含めるのが適当かもしれません。

[16] これに属するヘッダーは、 TRACE に対する応答に含めるべきではないでしょう。

文脈

[7] credentials は Authorization: ヘッダーや Proxy-Authorization: ヘッダーの値として使われます。

適用範囲と再利用

[5] 利用者エージェントがある credentials を自動的に適用できる範囲は、 ホストと realm による保護空間により決まります。 当該 creadentials 付きの要求が一旦認証されれば、 それを同じ空間の別の要求に対しても、 auth-scheme、 auth-param、 あるいは利用者の設定によって決まる期間、再利用して構いません。 >>1, >>8

[6] auth-scheme によって特に決められていない限り、 保護空間を鯖を超えて延長することはできません。 >>1, >>8

[26] 利用者エージェントによる credentials の保存の期間を満了させたり、 破棄させたりする方法は HTTP としては規定されていませんが、 認証方式によってはそのような仕組みを規定することもできます。 >>25

[27] 利用者エージェントは保存されている利用者が credentials を破棄できる仕組みを提供することを推奨 (encourage) されています >>25。

[30] 現在の Webブラウザーの一般的な実装では、ある保護空間に対する Webブラウザーのセッションの初回 401 応答では保存されているパスワードを補完した入力ダイアログボックスを表示し、 以後のアクセスでは予め credentials を指定した要求を送信するようになっています。

[31] 自動的な credentials の送信をやめるよう著者が鯖側から指示する 「ログアウト」機能が度々提案されていますが、そのような機能が必要な場合は Cookie認証が用いられることが多く、特に必要性は高く無いとして Webブラウザー開発者等の関心は高くないのが実情のようです。

[33] この Webブラウザーの自動的な credentials のため、 一つのホストを複数の著者が共有しているような場合に、 他の著者の資源に対するパスワードを受信することが可能となってしまいます。 realm を指定しても対策にはなりません >>32。

[38] 基本認証においては、 要求の対象URLから path 部分の最後の / の後の文字をすべて削除したものが、当該要求の認証範囲 (authentication scope) となります。 クライアントは、認証範囲と接頭辞一致する URL によって表される資源は、当該要求の realm で表されるのと同じ保護空間内にあるものと仮定するべきです。 >>42

[43] ダイジェスト認証も参照。

[41] クライアントは、サーバーから改めて challenge を受信せずとも、予め保護空間内の資源への要求に Authorization: ヘッダー (プロキシの認証の場合は Proxy-Authorization: ヘッダー) で基本認証の credentials を含めて送信できます >>42。

歴史