[20] challenge (誰何すいか) は、 HTTP認証において認証の方式と追加情報を記述し、 認証情報の送信を求めるものです。 WWW-Authenticate: ヘッダーで用いられています。

仕様書

構文

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

[4] auth-scheme のみの場合を除き、その後ろに1文字以上の SP が必要です。 >>6

HTTPにおける空白も参照。
  1. auth-scheme
  2. ?
    1. +
      1. SP
    2. |
      1. auth-param のリスト (#)
      2. token68
[2] RFC 1945 と RFC 2068 では realm 引数が最初の引数かつ必須とされていましたが、その後この制限はなくなっているようです。 更に RFC 7235 で token68 も認められるようになりました。

[21] auth-scheme より後の部分の構文は、 auth-scheme ごとに異なります。

[22] 詳しくは auth-scheme と各認証方式の項を参照。

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

誰何の選択

[11] 1つの要求の WWW-Authenticate: 欄には複数の誰何を含めることができます。 それぞれの誰何の auth-scheme は違っていても構いません。

[13] この時誰何の順は鯖が使って欲しい順序にするべきです。鯖はより「安全」 な方法を最初に持ってくるべきです。 >>10

[12] また利用者エージェントは提示された誰何のうち対応している最も「安全」な方法を選択するべきought to >>6 / 最も強い方法を選択しなければなりません >>34 / 選択するべきです >>35。

[36] MITM攻撃により不正なプロキシがダイジェスト認証を基本認証に差し替えるような形で合言葉を奪取しようとするかもしれません >>35。より安全でない認証方式に途中で変わらないか検査したり、 認証方式を利用者に提示したりする配慮が必要かもしれません >>35。

[14] RFC 2068 では、利用者エージェントは、対応しているより最初のものを使うべき、 かつ最も安全な方法を選択するべき >>10、と2つの矛盾する方針を同時に勧められていました。 RFC 2617 では >>12 だけを要求しており、しかもおすすめではなく、 必須 >>16 となっていました。 RFC 7235 では ought to になっています。

[5] RFC 7235 は、多くのクライアントで未知の auth-scheme が含まれている時構文解析に失敗するため、最初に Basic のような広く対応されている方式を指定して対処できると指摘しています。 >>6

[32] ダイジェスト認証は複数のダイジェストアルゴリズムに対応できる仕組みとなっています。 WWW-Authenticate: ヘッダーには auth-scheme が Digest の challenge を複数指定できます。 その場合、ダイジェストアルゴリズム (algorithm) は、すべて異なるものでなければなりません >>31。 順序は、優先度順としなければなりません >>31。

[33] クライアントは、複数の Digest challenge を受信したら、特に希望がなければ、最初の challenge を採用するべきです >>31。

authentication challenge

[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。

[26] realm 引数は、 HTTP認証一般で規定されている通りの意味を持ちます >>24。

[27] OAuth は基本認証やダイジェスト認証のように challenge に対して credentials を送信する形で利用するのは一般的ではないので、 challenge の必要性は低く、実際に使われることはそう多くは無いようです。

レンダリング

[29] 401 応答のレンダリングについては、 401 の項を参照。

[30] 利用者エージェントは、それ以外の応答であっても、 challenge が含まれていれば (非モーダルダイアログにより) 利用者が認証できるようにするべきです >>28。

歴史

RFC 第1世代 (RFC 1945)

  • [1] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-11

RFC 第2世代 (RFC 2068)

  • [9] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-11
  • [10] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-15.2

RFC 第3世代 (RFC 2617)

  • [15] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-1.2
  • [16] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-4.6

RFC 第4世代 (RFC 7235)

  • [19] RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication ( 版) https://tools.ietf.org/html/rfc7235#section-2.1

関連

[7] 認証情報をクライアントから鯖に送信する際には credentials を使います。 challenge と credentials は一般的な構文としては同じですが、 auth-scheme 依存の構文としては違うことがあります。