[11] WWW-Authenticate: ヘッダーは、 当該対象資源へのアクセスに必要な認証についての情報を含む challengechallenge (HTTP) を指定するものです。

仕様書

意味

[5] WWW-Authenticate: ヘッダーは、 対象資源に適用できる認証方式(群)と認証引数を示します >>3。

構文

[414] WWW-Authenticate: ヘッダーの値は、 1つ以上の challengechallenge (HTTP) のリストリスト (HTTP) (#) です >>3, >>413, >>417。

  1. challengechallenge (HTTP)
  2. *
    1. OWS
    2. ,
    3. OWS
    4. challengechallenge (HTTP)

読点

[1] この欄は、読点で分離することで複数の誰何を併記できます。 ところが、他の同様の欄とは異なり、誰何自体が引数の分離のために読点を使ってしまっています。 auth-scheme があるので構文上曖昧性はないのですが、 このために (欄名に依存しない) 汎用の構文解析器で複数の誰何を分離することができません。

おそらくこのような困った仕様になった原因は太古の HTTP では読点とセミコロンが曖昧に使われていたときの名残でしょう。

[8] 実装によっては、複数の challengechallenge (HTTP) の指定に対応していないことがあります。 鯖は複数の challengechallenge (HTTP) の指定を避けるべきでしょう。

文脈

[407] 鯖は、 401 応答を生成する場合、 1つ以上の challengechallenge (HTTP) を含む WWW-Authenticate: ヘッダーを送信しなければなりません。 >>3, >>406, >>413, >>417, >>408, >>409, >>411, >>416。

[6] 鯖は、credentials を指定すると (あるいは他の credentials に変更すると) 応答に影響するかもしれないことを示すため、 他の応答でも WWW-Authenticate: ヘッダーを生成して構いません >>3。

[424] RFC 4559 は 200 でも WWW-Authenticate: ヘッダーを用いるとしています。

Negotiate の項を参照。

[7] WWW-Authenticate: ヘッダーは複数指定できます >>3。

処理

[10] HTTP認証も参照。

[410] プロキシは、転送の際に WWW-Authenticate: ヘッダーを変更してはなりません >>3, >>409, >>412, >>419, >>17。

OAuth

[421] OAuth 1.0 を使う場合、 auth-scheme が OAuth である WWW-Authenticate: 欄を含めても構わない >>420 とされています。

[422] OAuth の場合は事前に OAuth を使うと分かっていて要求を発行するのが一般的なので、 WWW-Authenticate: 欄の必要性はあまりなく、実際に必須とはされていません。[12] 401 応答では WWW-Authenticate: ヘッダーが必須ですから (>>407)、OAuth のみを使う場合で 401 を返すなら、 >>421 は MAY ではなく MUST ということになります。

関連

[18] WWW-Authenticate: ヘッダーは、 要求に適切な credentials が含まれず認証に失敗した時に使います。 認証に成功した時のサーバーからクライアントへの情報伝達には、 Authentication-Info: ヘッダーが使われます。

歴史

RFC 第1世代

  • [406] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-10.16
  • [408] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#page-36
  • [409] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-11

RFC 第2世代

  • [411] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-10.4.2
  • [412] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#page-66
  • [413] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-14.46

RFC 第3世代

  • [416] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2616#section-10.4.2
  • [417] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2616#section-14.47
  • [419] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#page-5
[403] RFC 1945 (HTTP/1.0) 10.16; RFC 2068 (HTTP/1.1) 14.46; RFC 2616 (HTTP/1.1) 14.47 WWW-Authenticate[404] 注記のない変更点は、 RFC 1945→RFC 2068 のもの。

The WWW-Authenticate response-header field must MUST be included in 401 (unauthorized Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.

WWW-Authenticate 応答頭欄は、 401 (未認証) 応答メッセージに含められなければなりません。 欄値は、最低一つの誰何で構成します。 誰何は、その Request-URI に適用可能な認証方式および引数を示します。

  • WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

The HTTP access authentication process is described in section 11 {2616} "HTTP Authentication: Basic and Digest Access Authentication" [43] . User agents must MUST are advised to take special care in parsing the WWW-Authenticate field value if it {2616} as it might contains {1945,2068} more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself {2616} the contents of a challenge itself can contain a comma-separated list of authentication parameters.

HTTP 接続認証処理は RFC2617 で説明されています。 利用者エージェントは WWW-Authenticate 欄値を構文解析するに当たって特別の注意を払うように助言しておきます。 欄値は複数の誰何を含むかもしれませんし、 複数の WWW-Authenticate 頭欄が提供されているなら、 誰何の内容自体が認証引数群の読点分離並びを含むかもしれません。

RFC 第4世代

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

実装

[2] realm にセミコロンが含まれると、 (quoted-string にしているのに) ClassicMozilla はセミコロン前でぶった切ってしまいます。 (そのくせ、引用開始の引用符はちゃんと省いて表示してくれる。) (NN2, NC 4.01 で確認。)

WinIE1 ですらこんなことはありませんでした。

なんと、 Mosaic Netscape 0.9 は正しく処理します。

[402] フォームの提出先が基本認証の時の動作が変なブラウザーがありますね。 Gecko とか WinIE とか WebKit とか。最初必ず認証なしで試して、 401 なら再試行するところ、なぜか再試行しようとして接続を試みたままだったり。 Firefox だと最初の1回目だけ変なことがあって次からはうまくいくみたいですが。 リンク先が違うディレクトリだったりとかも関係してるっぽ。 Safari と Chrome の間でもなんかちがうな。。。

例

[9] HTTP 仕様書 >>3 では次のような架空の認証方式と基本認証を併用した例が示されています。

WWW-Authenticate: Newauth realm="apps", type=1,
                  title="Login to \"apps\"", Basic realm="simple"

関連

[405] 起源鯖ではなく、途中の串について行う認証のための Proxy-Authenticate: 欄もあります。