auth-param

認証引数 (HTTP)

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

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

仕様書

構文

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

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

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

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

  1. 字句
  2. =
  3. |
    1. 字句
    2. 引用文字列
[34] 引数も参照。

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

[22] RFC 1945RFC 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

auth-param のリスト

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

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

[6] MIMEHTTP の他のヘッダーでは引数; で区切るのが普通ですが、 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

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

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

consumer keyaccess 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

[38] Digest認証では未知の引数は無視しなければなりません >>39, >>42

引数の一覧

[78] challengecredentials では、次のような引数が用いられます。

[8] RFC 1945RFC 2068 では ABNF 構文上 realm 引数auth-param に含まれないことになっていました。 RFC 2069RFC 2617RFC 7235 では realmauth-param の部分に含まれています。

[74] >>73SIP に関する IANA登録簿があります。

[72] JSON 形式の一覧データファイルが >>71 にあります。

[79] Authentication-Info:Proxy-Authentication-Info: で用いられるものについては、そちらの項を参照。

歴史

RFC 第1世代 (RFC 1945)

RFC 第2世代 (RFC 2068)

RFC 第3世代 (RFC 2617)

RFC 第4世代 (RFC 7235)