[20] challenge (誰何) は、
HTTP認証において認証の方式と追加情報を記述し、
認証情報の送信を求めるものです。 WWW-Authenticate:
ヘッダーで用いられています。
[3] challenge は、 auth-scheme のみか、
その後に auth-param のリスト (#)
または token68 を続けたものです。 >>6
[4] auth-scheme のみの場合を除き、その後ろに1文字以上の
SP が必要です。 >>6
realm
引数が最初の引数かつ必須とされていましたが、その後この制限はなくなっているようです。
更に RFC 7235 で token68 も認められるようになりました。[21] auth-scheme より後の部分の構文は、
auth-scheme ごとに異なります。
[23] token68 は既存の認証方式の構文との互換性のためのもので、
新しい認証方式は使うべきではありません >>8。
[11] 1つの要求の WWW-Authenticate: 欄には複数の誰何を含めることができます。
それぞれの誰何の auth-scheme は違っていても構いません。
[13] この時誰何の順は鯖が使って欲しい順序にするべきです。鯖はより「安全」 な方法を最初に持ってくるべきです。 >>10
[12] また利用者エージェントは提示された誰何のうち対応している最も「安全」な方法を選択するべき >>6 / 最も強い方法を選択しなければなりません >>34 / 選択するべきです >>35。
[36] MITM攻撃により不正なプロキシがダイジェスト認証を基本認証に差し替えるような形で合言葉を奪取しようとするかもしれません >>35。より安全でない認証方式に途中で変わらないか検査したり、 認証方式を利用者に提示したりする配慮が必要かもしれません >>35。
[14] RFC 2068 では、利用者エージェントは、対応しているより最初のものを使うべき、 かつ最も安全な方法を選択するべき >>10、と2つの矛盾する方針を同時に勧められていました。 RFC 2617 では >>12 だけを要求しており、しかもおすすめではなく、 必須 >>16 となっていました。 RFC 7235 では ought to になっています。
auth-scheme
が含まれている時構文解析に失敗するため、最初に Basic
のような広く対応されている方式を指定して対処できると指摘しています。 >>6[32] ダイジェスト認証は複数のダイジェストアルゴリズムに対応できる仕組みとなっています。
WWW-Authenticate: ヘッダーには auth-scheme
が Digest の challenge を複数指定できます。
その場合、ダイジェストアルゴリズム (algorithm)
は、すべて異なるものでなければなりません >>31。
順序は、優先度順としなければなりません >>31。
[33] クライアントは、複数の Digest challenge
を受信したら、特に希望がなければ、最初の challenge
を採用するべきです >>31。
[18] RFC 7231 では次のヘッダーが authentication challenge
に分類されています >>17。
[37] それ以外で Optional-WWW-Authenticate: でも
challenge が使われます。
WWW-Authenticate: OAuth の challenge[25] OAuth 1.0 の鯖は、保護資源に対する応答に
WWW-Authenticate: OAuth ヘッダーを含めて
OAuth 1.0 への対応を示すことができます >>24。
[29] 401 応答のレンダリングについては、
401 の項を参照。
[30] 利用者エージェントは、それ以外の応答であっても、 challenge が含まれていれば (非モーダルダイアログにより) 利用者が認証できるようにするべきです >>28。
[7] 認証情報をクライアントから鯖に送信する際には credentials
を使います。 challenge と credentials は一般的な構文としては同じですが、
auth-scheme 依存の構文としては違うことがあります。