認証引数 (HTTP)

[7] HTTP認証の challenge や credentials における引数は auth-param >>3 や authentication parameter >>3 と呼ばれています。

[83] Authentication-Control: ヘッダーでは、 auth-param と似て非なる auth-control-param >>82 が使われています。

構文

[5] auth-param は、名前と値の組を = で連結したものです。 = の前後には BWS が挟まります。 >>3

[33] 名前は字句です。大文字・小文字不区別です。 >>3

[14] RFC 1945 / RFC 2068 は realm 属性以外について大文字と小文字の解釈を明記していませんでした。

[63] 値は字句または引用文字列です。 >>3

[34] 引数も参照。

[2] RFC 1945 と RFC 2068 では値は引用文字列とされていました。 RFC 2617 以後字句も認められています。

[22] RFC 1945 と RFC 2068 の定義では必ず引用文字列とすることになっていましたが、 RFC 2069 ではそうなっていない構文が定義されており、矛盾していました。

[36] 更に、各引数について個別の値の構文が定義されています。

[68] RFC 2616 世代までは、例によって引数ごとの個別の ABNF 構文は quoted-string の引用符まで含めて特定の構文を決める形になっていました。現実にはまず token または quoted-string として構文解析した後にその値の部分を取り出して処理するのが一般的だと思われます。 RFC 723x 世代からはそのような形に改められています。 RFC 7235 もそのように定義することを求めて (ought to) います >>67。

[69] realm 引数の値は字句ではなく引用文字列としなければならないとされています。ただしこのような制限は新しい引数には設けるべきではない (ought to) とされています >>67。

[80] Authentication-Info:/Proxy-Authentication-Info: については、原則として字句と引用文字列の両方の送受信に対応するべきこと、後方互換性のためどちらで送信するべきか規定できることが RFC で説明されています。

両ヘッダーの項を参照。

文字コード

[64] RFC 2616 まではヘッダーの文字コードは ISO-8859-1 とされていましたが、 RFC 723x では US-ASCII になっており、8ビットのオクテットの解釈は不明となっています。

[65] 実際には利用者名や合言葉などで非ASCII文字が使われることがあります。その扱いは auth-scheme に依りますが、明確に規定されているものもあれば、されていないものもあります。

[66] OAuth 1.0 ではパーセント符号化を使っています (>>55)。

[81] ダイジェスト認証の username/username* 引数では、 RFC 5987 の拡張が使われています。

[86] Mutual では、 credentials, challenge, Authentication-Info:/Proxy-Authentication-Info: で RFC 5987 の拡張が使われています。ただし realm 引数では禁止されています。 >>85

[21] Bug 41489 - http authentication does not support non-ASCII characters https://bugzilla.mozilla.org/show_bug.cgi?id=41489

`auth-param` のリスト

[13] auth-param は引数の1対ですが、実際にはリスト (#) として用いられます。

?
1. auth-param
2. *
  1. FWS
  2. ,
  3. FWS
  4. auth-param

[6] MIME や HTTP の他のヘッダーでは引数は ; で区切るのが普通ですが、 auth-param のリストでは , で区切ります。

[9] そのため WWW-Authenticate: や Proxy-Authenticate: や Authorization: はHTTPヘッダーの連結の処理の際に注意が必要です。

[35] 古くは HTTP では引数の区切りは , でしたが、 MIME に揃えるため RFC 1945 時代より前に ; に変更されました。なぜ auth-param だけ , のまま残ったのかは不明ですが、他の引数を値とするヘッダーは理論上存在しても実際には使われていなかった一方、認証は早くからしばしば用いられていたため変更できなかったのかもしれません。

[15] challenge では >>3 同じ名前の引数を複数回使うことは認められていません。

[12] credentials では順序は特に規定されていないようです。

[11] RFC 1945/RFC 2068 の定義では、誰何においては realm 引数は唯一、 auth-scheme に関わらず必須で構文的にも最初に定義されている特殊な引数でした。ただ最初の引数でなければならないのが ABNF 構文の定義上のものなのか、現実にそうでなければならない要件なのかははっきりしませんでした。

[84] auth-control-param は似ていますが、少し違います。 RFC 5987 の拡張構文にも対応しています。

OAuth 1.0 用の表現

[51] OAuth 1.0 ではプロトコル引数を Authorization: ヘッダーで auth-param として指定することができ、その場合の構文が HTTP 本体よりも厳密に規定されています。 >>50

[55] 引数の名前と値はまず OAuth 1.0パーセント符号化しておきます。
[52] 引数の名前と値の間に LWS を入れることはできません。
[53] 引数の値は引用文字列としなければなりません。
[54] 引数の値で quoted-pair は使いません。
[56] 引数の区切りには , と SP、または , だけを使います。

[16] 引数の名前は字句なので、 % を含めることができます。

[75] 解釈の方法はなぜか規定されていません。記号や非ASCII文字の値が含まれることがあり得るので、それをどう処理するか規定がないと相互運用性に影響しそうですが・・・。

consumer key や access token に記号や非ASCII文字を含めるのは、避けるべきでしょう。

[76] この構文で符号化される値については、要求引数を参照。

文脈

[20] auth-param はリスト (#) として用いられます。

[17] challenge (誰何) では、 auth-scheme に続けて指定し、必要な認証についての追加情報を表します。

[18] credentials では、 auth-scheme に続けて指定し、認証に必要な情報を表します。

[77] Authentication-Info:, Proxy-Authentication-Info: 両ヘッダーでも使われています。

未知の引数

[70] 未知の引数についての共通の処理の方法はありません。認証方式を定義する際はどのように扱うか決めるべき (ought to) とされています >>67。その際、「理解しなければならない」ではなく「無視しなければならない」とするのが好ましい (prefer) とされています >>67。また新しい引数を規定する方法 (仕様書の改訂や登録簿など) も定めるべき (ought to) とされています >>67。