4. ヘッダフィールドの定義 (Header Field Definitions)
本節では、HTTP 認証フレームワークに関連するヘッダーフィールドの構文と意味論を定義する。
4.1 WWW-Authenticate
"WWW-Authenticate" ヘッダーフィールドは、対象リソースに適用可能な認証スキームとパラメーターを示す。
WWW-Authenticate = 1#challenge
401 (Unauthorized) 応答を生成するサーバーは、少なくとも 1 つのチャレンジを含む WWW-Authenticate ヘッダーフィールドを送信しなければならない (MUST)。サーバーは、資格情報 (または異なる資格情報) を提供することが応答に影響を与える可能性があることを示すために、他の応答メッセージで WWW-Authenticate ヘッダーフィールドを生成してもよい (MAY)。
応答を転送するプロキシは、その応答内の WWW-Authenticate フィールドを変更してはならない (MUST NOT)。
ユーザーエージェントは、フィールド値の解析に特別な注意を払うよう勧められる。これは複数のチャレンジを含む可能性があり、各チャレンジはカンマ区切りの認証パラメーターのリストを含むことができるためである。さらに、ヘッダーフィールド自体が複数回出現することもある。
例えば:
WWW-Authenticate: Newauth realm="apps", type=1,
title="Login to \"apps\"", Basic realm="simple"
このヘッダーフィールドは 2 つのチャレンジを含む。1 つは realm 値 "apps" を持つ "Newauth" スキームのもので、追加パラメーター "type" と "title" を持ち、もう 1 つは realm 値 "simple" を持つ "Basic" スキームのものである。
注記: challenge の文法生成規則もリスト構文を使用する。したがって、カンマ、空白、カンマの並びは、先行するチャレンジに適用されるものと見なすことも、チャレンジのリスト内の空のエントリであると見なすこともできる。実際には、この曖昧さはヘッダーフィールド値の意味論に影響を与えないため、無害である。
4.2 Authorization
"Authorization" ヘッダーフィールドにより、ユーザーエージェントはオリジンサーバーに対して自身を認証できる。通常は 401 (Unauthorized) 応答を受信した後であるが、必ずしもそうとは限らない。その値は、要求されているリソースの realm に対するユーザーエージェントの認証情報を含む資格情報からなる。
Authorization = credentials
リクエストが認証され、realm が指定されている場合、同じ資格情報がこの realm 内の他のすべてのリクエストに対して有効であると推定される (認証スキーム自体が、チャレンジ値に応じて変化する資格情報や同期されたクロックの使用など、別のことを要求しないと仮定する)。
リクエストを転送するプロキシは、そのリクエスト内の Authorization フィールドを変更してはならない (MUST NOT)。HTTP キャッシュによる Authorization フィールドの処理に関する詳細と要件については、[RFC7234] の 3.2 節を参照されたい。
4.3 Proxy-Authenticate
"Proxy-Authenticate" ヘッダーフィールドは、この実効リクエスト URI ([RFC7230] の 5.5 節) についてプロキシに適用可能な認証スキームとパラメーターを示す少なくとも 1 つのチャレンジからなる。プロキシは、自身が生成する各 407 (Proxy Authentication Required) 応答において、少なくとも 1 つの Proxy-Authenticate ヘッダーフィールドを送信しなければならない (MUST)。
Proxy-Authenticate = 1#challenge
WWW-Authenticate とは異なり、Proxy-Authenticate ヘッダーフィールドは、応答チェーン上の次に位置する送信側クライアント (outbound client) にのみ適用される。これは、特定のプロキシを選択したクライアントだけが認証に必要な資格情報を持っている可能性が高いためである。しかし、大規模な企業ネットワーク内のオフィスや地域のキャッシュプロキシのように、複数のプロキシが同じ管理ドメイン内で使用される場合、資格情報がユーザーエージェントによって生成され、消費されるまで階層を通過するのが一般的である。したがって、そのような構成では、各プロキシが同じチャレンジ集合を送信するため、Proxy-Authenticate が転送されているように見える。
WWW-Authenticate の解析に関する考慮事項は、このヘッダーフィールドにも適用されることに注意されたい。詳細は 4.1 節を参照されたい。
4.4 Proxy-Authorization
"Proxy-Authorization" ヘッダーフィールドにより、クライアントは認証を要求するプロキシに対して自身 (またはそのユーザー) を識別できる。その値は、そのプロキシおよび/または要求されているリソースの realm に対するクライアントの認証情報を含む資格情報からなる。
Proxy-Authorization = credentials
Authorization とは異なり、Proxy-Authorization ヘッダーフィールドは、Proxy-Authenticate フィールドを使用して認証を要求した次に位置する受信側プロキシ (inbound proxy) にのみ適用される。チェーン内で複数のプロキシが使用される場合、Proxy-Authorization ヘッダーフィールドは、資格情報を受信することを期待していた最初の受信側プロキシによって消費される。プロキシは、それによってプロキシが特定のリクエストを協調的に認証するメカニズムである場合、クライアントリクエストからの資格情報を次のプロキシに中継してもよい (MAY)。