[30] Authentication-Info: は起源サーバーの、
Proxy-Authentication-Info: はプロキシの
HTTP認証に関する情報をサーバーからクライアントへと伝送するための
HTTPヘッダーです。
仕様書
- [15] RFC 7615 - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields ( 版) https://tools.ietf.org/html/rfc7615
- [11] RFC 4976 - Relay Extensions for the Message Sessions Relay Protocol (MSRP) ( 版) https://tools.ietf.org/html/rfc4976#section-4.5
- [31] RFC 7616 - HTTP Digest Access Authentication ( 版) https://tools.ietf.org/html/rfc7616#section-3.5
- [35] RFC 7616 - HTTP Digest Access Authentication ( 版) https://tools.ietf.org/html/rfc7616#section-3.6
- [36] RFC 7616 - HTTP Digest Access Authentication ( 版) https://tools.ietf.org/html/rfc7616#section-3.8
- [40] RFC 8120 - Mutual Authentication Protocol for HTTP () https://tools.ietf.org/html/rfc8120#section-3.1
意味
[16] 認証方式は、クライアントの認証 credentials
を承認したら、情報伝達のために Authentication-Info:
応答ヘッダーを使うことができます >>15。
[25] Proxy-Authentication-Info: ヘッダーは、
Authentication-Info: ヘッダーと同様のものですが、
プロキシの認証に用いられます >>15, >>36。
[21] 本ヘッダーの意味は、要求の Authorization:
ヘッダーまたは Proxy-Authorization:
ヘッダーで示された認証方式により定義されます >>15。
[22] 特に定義がない場合どう解釈するべきなのかは不明です。無視するのが適切そうではありますが。構文
[17] 値は、 auth-param のリスト (#)
です >>15。
auth-param- *
- FWS
,- FWS
auth-param
[24] 引数の値は字句と引用文字列の両方を送受信できなければなりません。
しかし後方互換性のため認証方式次第で送信者がどちらを使うべきか制限しても構いません。
>>15
[41] RFC 8120 は (Mutual の場合のみ?) RFC 5987 の拡張構文を用いることができるとしています
>>40。
しかし RFC 7615 は認証方式依存で拡張構文を使って良いと明示的に認めてはおらず、
既存の実装が RFC 8120 の要求を満たせるのかどうかは謎です。
auth-param も参照。引数
[18] 認証方式ごとに利用する引数を規定できます >>15。
- [7]
cnonce >>5, >>31 - [3]
digest >>1 - [2]
nextnonce >>1, >>5, >>31 - [6]
nc >>5, >>31 - [9]
rspauth >>5, >>31 - [8]
qop >>5, >>31
文脈
[19] Authentication-Info: ヘッダーは、
要求メソッドや状態符号に関わらず、
任意の応答で使うことができます >>15。
[20] HTTP認証を使わない場面でも使うことができるのかどうかは定かではありません。[33] ダイジェスト認証では、サーバーは、認証に成功したら応答にヘッダーを含めることができます
>>31。
[10] Authentication-Info: ヘッダーは、
認証方式が認める場合は >>15、トレーラー部でも使えます >>5, >>15。
[38] SCRAM が認めています >>37。
[34] ダイジェスト認証では、使うことができます >>31。
[26] Proxy-Authentication-Info: について明記されていませんが、
同様と思われます。処理
[23] 応答を転送するプロキシは、 Authentication-Info:
ヘッダーを変更してはなりません >>15, >>35。
[27] Proxy-Authentication-Info: ヘッダーは外向きの次のクライアントに向けたもので、
転送しないのが普通です。しかしプロキシが多段になっていて下流から
credentials を受け取って転送したような場合には、
Proxy-Authentication-Info: ヘッダーが転送されることもあります。
>>15
歴史
- [1] RFC 2069 - An Extension to HTTP : Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2069#section-2.1.3
- [14] RFC 2069 - An Extension to HTTP : Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2069#section-2.5
- [4] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-3.2.3
- [5] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-3.2.3
- [13] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-3.6
[12] Session Initiation Protocol (SIP) Parameters
( ( 版))
http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12
[28] RFC 2617 の改訂である RFC 7615 は、
Digest認証以外への適用可能性を理由に >>15、 Authentication-Info:
と Proxy-Authentication-Info: を独立した RFC
としています。
[29] それなら RFC 7235 に入れておけばよかったように思いますが...[32] ダイジェスト認証に関する規定は RFC 7616 に移行しています。
[37] RFC 7804 - Salted Challenge Response HTTP Authentication Mechanism
( 版)
https://tools.ietf.org/html/rfc7804#section-6When used with SCRAM, the Authentication-Info header field is allowed
in the trailer of an HTTP message transferred via chunked transfer-
coding.
[39] RFC 8120 - Mutual Authentication Protocol for HTTP
()
https://tools.ietf.org/html/rfc8120#section-14
[42] Issues · httpwg/http-extensions
()
https://github.com/httpwg/http-extensions/issues?utf8=%E2%9C%93&q=label%3Aauth-info