誰何

challenge (HTTP)

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

仕様書

構文

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

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

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

[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-schemeDigestchallenge を複数指定できます。 その場合、ダイジェストアルゴリズム (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)

RFC 第2世代 (RFC 2068)

RFC 第3世代 (RFC 2617)

RFC 第4世代 (RFC 7235)

関連

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