11. HTTP認証 (HTTP Authentication)
11.1. 認証スキーム (Authentication Scheme)
HTTPは、拡張可能なチャレンジ-レスポンス認証スキームのセットを通じて、アクセス制御と認証のための一般的なフレームワークを提供します。サーバーはこれを使用してクライアントリクエストにチャレンジでき、クライアントはこれを使用して認証情報を提供できます。認証スキームを識別するために、大文字小文字を区別しないトークンを使用します：
auth-scheme = token
この一般的なフレームワーク以外に、この文書は認証スキームを指定していません。新規および既存の認証スキームは独立して指定され、「Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry」に登録される必要があります。たとえば、「basic」および「digest」認証スキームは、それぞれ[RFC7617]および[RFC7616]によって定義されています。
11.2. 認証パラメータ (Authentication Parameters)
認証スキームの後には、そのスキームを介して認証を達成するために必要な追加情報が続きます。これは、カンマ区切りのパラメータリストまたはbase64エンコード情報を保持できる単一の文字シーケンスのいずれかです。
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
token68構文は、66個の予約されていないURI文字（[URI]）に加えて他のいくつかの文字を許可するため、空白を除いて、パディングの有無にかかわらず、base64、base64url（URLおよびファイル名セーフアルファベット）、base32、またはbase16（16進数）エンコーディングを保持できます（[RFC4648]）。
認証パラメータは名前/値のペアであり、名前トークンは大文字小文字を区別せずに一致し、各パラメータ名はチャレンジごとに1回のみ出現できます。
auth-param = token BWS "=" BWS ( token / quoted-string )
パラメータ値は、「token」または「quoted-string」として表現できます（セクション5.6）。認証スキーム定義は、送信者と受信者の両方について両方の表記を受け入れる必要があり、受信者が認証スキームに関係なく汎用解析コンポーネントを使用できるようにします。
下位互換性のため、認証スキーム定義は、送信者のフォーマットを2つのバリアントのいずれかに制限できます。これは、デプロイされた実装が2つのフォーマットのいずれかに遭遇したときに失敗することが知られている場合に重要です。
11.3. チャレンジとレスポンス (Challenge and Response)
オリジンサーバーは、401（Unauthorized）レスポンスメッセージを使用してユーザーエージェントの承認にチャレンジし、リクエストされたリソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダフィールドを含めます。
プロキシは、407（Proxy Authentication Required）レスポンスメッセージを使用してクライアントの承認にチャレンジし、リクエストされたリソースのプロキシに適用可能な少なくとも1つのチャレンジを含むProxy-Authenticateヘッダフィールドを含めます。
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
注意： 多くのクライアントは、未知のスキームを含むチャレンジの解析に失敗します。この問題の回避策は、よくサポートされているスキーム（「basic」など）を最初にリストすることです。
オリジンサーバーで自身を認証したいユーザーエージェントは、通常は401（Unauthorized）を受信した後ですが、必ずしもそうではありませんが、リクエストにAuthorizationヘッダフィールドを含めることでそうできます。
プロキシで自身を認証したいクライアントは、通常は407（Proxy Authentication Required）を受信した後ですが、必ずしもそうではありませんが、リクエストにProxy-Authorizationヘッダフィールドを含めることでそうできます。
11.4. 認証情報 (Credentials)
Authorizationフィールド値とProxy-Authorizationフィールド値の両方には、レスポンスで受信したチャレンジ（おそらく過去のある時点で）に基づいて、リクエストされているリソースのレルムに対するクライアントの認証情報が含まれます。それらの値を作成する際、ユーザーエージェントは、最も安全だと考えるauth-schemeを持つチャレンジを選択し、必要に応じてユーザーから認証情報を取得することによって、そうすべきです。ヘッダフィールド値内での認証情報の送信は、セクション17.16.1で説明されているように、基礎となる接続の機密性に関する重要なセキュリティ上の考慮事項を意味します。
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
認証情報を省略した、無効な認証情報（たとえば、間違ったパスワード）を含む、または部分的な認証情報（たとえば、認証スキームが複数のラウンドトリップを必要とする場合）を含む保護されたリソースのリクエストを受信すると、オリジンサーバーは、リクエストされたリソースに適用可能な少なくとも1つの（おそらく新しい）チャレンジを含むWWW-Authenticateヘッダフィールドを含む401（Unauthorized）レスポンスを送信すべきです（SHOULD）。
同様に、プロキシ認証情報を省略した、または無効なまたは部分的なプロキシ認証情報を含むリクエストを受信すると、認証を必要とするプロキシは、プロキシに適用可能な少なくとも1つの（おそらく新しい）チャレンジを含むProxy-Authenticateヘッダフィールドを含む407（Proxy Authentication Required）レスポンスを生成すべきです（SHOULD）。
アクセスを得るには十分でない有効な認証情報を受信したサーバーは、403（Forbidden）ステータスコードで応答すべきです（セクション15.5.4）。
HTTPは、アクセス認証のためにこの単純なチャレンジ-レスポンスフレームワークにアプリケーションを制限しません。トランスポートレベルでの認証やメッセージのカプセル化を介した認証、および認証情報を指定する追加のヘッダフィールドなど、追加のメカニズムを使用できます。ただし、このような追加のメカニズムは、この仕様では定義されていません。
さまざまなカスタムユーザー認証メカニズムは、[COOKIE]で定義されているSet-CookieおよびCookieヘッダフィールドを使用して、認証関連のトークンを運ぶために実装されていることに注意してください。
11.5. 保護空間（レルム）の確立 (Establishing a Protection Space (Realm))
「realm」認証パラメータは、保護の範囲を示したい認証スキームによる使用のために予約されています。
保護空間は、アクセスされているサーバーのオリジン（セクション4.3.1を参照）と、存在する場合はレルム値との組み合わせによって定義されます。これらのレルムにより、サーバー上の保護されたリソースを、それぞれが独自の認証スキームおよび/または承認データベースを持つ保護空間のセットに分割できます。レルム値は文字列であり、通常はオリジンサーバーによって割り当てられ、認証スキームに固有の追加のセマンティクスを持つことができます。レスポンスは、同じauth-schemeを持つが異なるレルムを持つ複数のチャレンジを持つことができることに注意してください。
保護空間は、認証情報を自動的に適用できるドメインを決定します。以前のリクエストが承認されている場合、ユーザーエージェントは、認証スキーム、パラメータ、および/またはユーザー設定（構成可能な非アクティブタイムアウトなど）によって決定される期間、その保護空間内の他のすべてのリクエストに対して同じ認証情報を再利用してもかまいません（MAY）。
保護空間の範囲、したがってクライアントが認証情報を自動的に適用する可能性のある場所は、追加情報がない限り、クライアントには必ずしもわかりません。認証スキームは、保護空間の範囲を記述するパラメータを定義する場合があります。認証スキームで特に許可されていない限り、保護空間はサーバーの範囲外に拡張できません。
歴史的な理由により、送信者はquoted-string構文のみを生成しなければなりません（MUST）。受信者は、tokenとquoted-string構文の両方をサポートする必要がある場合があり、長い間両方の表記を受け入れてきた既存のクライアントとの最大の相互運用性を実現します。
11.6. ユーザーをオリジンサーバーに認証する (Authenticating Users to Origin Servers)
11.6.1. WWW-Authenticate
「WWW-Authenticate」レスポンスヘッダフィールドは、ターゲットリソースに適用可能な認証スキームとパラメータを示します。
WWW-Authenticate = #challenge
401（Unauthorized）レスポンスを生成するサーバーは、少なくとも1つのチャレンジを含むWWW-Authenticateヘッダフィールドを送信しなければなりません（MUST）。サーバーは、認証情報（または異なる認証情報）を提供するとレスポンスに影響を与える可能性があることを示すために、他のレスポンスメッセージでWWW-Authenticateヘッダフィールドを生成してもかまいません（MAY）。
レスポンスを転送するプロキシは、そのレスポンス内のWWW-Authenticateヘッダフィールドを変更してはなりません（MUST NOT）。
ユーザーエージェントは、フィールド値を解析する際に特別な注意を払うことをお勧めします。複数のチャレンジが含まれている可能性があり、各チャレンジにはカンマ区切りの認証パラメータのリストが含まれている可能性があるためです。さらに、ヘッダフィールド自体が複数回出現する可能性があります。
例えば：
WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\""
このヘッダフィールドには、2つのチャレンジが含まれています。1つは「Basic」スキーム用で、レルム値が「simple」、もう1つは「Newauth」スキーム用で、レルム値が「apps」です。また、「type」と「title」という2つの追加パラメータも含まれています。
ただし、一部のユーザーエージェントはこの形式を認識しません。したがって、同じフィールド行に複数のメンバーを含むWWW-Authenticateフィールド値を送信することは、相互運用できない可能性があります。
注意： チャレンジ文法生成もリスト構文を使用します。したがって、カンマ、空白、カンマのシーケンスは、前のチャレンジに適用されると見なすことも、チャレンジリスト内の空のエントリであると見なすこともできます。実際には、この曖昧さはヘッダフィールド値のセマンティクスに影響を与えないため、無害です。
11.6.2. Authorization
「Authorization」ヘッダフィールドにより、ユーザーエージェントはオリジンサーバーで自身を認証できます。通常は401（Unauthorized）レスポンスを受信した後ですが、必ずしもそうではありません。その値は、リクエストされているリソースのレルムに対するユーザーエージェントの認証情報を含む認証情報で構成されます。
Authorization = credentials
リクエストが認証され、レルムが指定されている場合、同じ認証情報は、このレルム内の他のすべてのリクエストに対して有効であると推定されます（認証スキーム自体が、チャレンジ値に応じて変化する認証情報や同期クロックの使用など、他の方法を必要としない限り）。
リクエストを転送するプロキシは、そのリクエスト内のAuthorizationヘッダフィールドを変更してはなりません（MUST NOT）。HTTPキャッシュによるAuthorizationヘッダフィールドの処理に関する詳細と要件については、[CACHING]のセクション3.5を参照してください。
11.6.3. Authentication-Info
HTTP認証スキームは、「Authentication-Info」レスポンスフィールドを使用して、クライアントの認証情報が受け入れられた後に情報を伝達できます。この情報には、サーバーからの最終メッセージが含まれる場合があります（たとえば、サーバー認証が含まれる場合があります）。
フィールド値は、セクション11.3で定義された「auth-param」構文を使用するパラメータ（名前/値のペア）のリストです。この仕様は一般的な形式のみを説明します。Authentication-Infoを使用する認証スキームは、個々のパラメータを定義します。たとえば、「Digest」認証スキームは、[RFC7616]のセクション3.5で複数のパラメータを定義しています。
Authentication-Info = #auth-param
Authentication-Infoフィールドは、リクエストメソッドとステータスコードに関係なく、任意のHTTPレスポンスで使用できます。そのセマンティクスは、対応するリクエストのAuthorizationヘッダフィールド（セクション11.6.2）によって示される認証スキームによって定義されます。
レスポンスを転送するプロキシは、フィールド値をいかなる方法でも変更することはできません。
Authentication-Infoは、認証スキームで明示的に許可されている場合、メッセージ本文が送信されることが明らかになったら（たとえば、認証が拒否されない場合）、トレーラフィールド（セクション6.5）として送信できます。
11.7. クライアントをプロキシに認証する (Authenticating Clients to Proxies)
11.7.1. Proxy-Authenticate
「Proxy-Authenticate」ヘッダフィールドは、このリクエストのプロキシに適用可能な認証スキームとパラメータを示す少なくとも1つのチャレンジで構成されます。プロキシは、生成する各407（Proxy Authentication Required）レスポンスで少なくとも1つのProxy-Authenticateヘッダフィールドを送信しなければなりません（MUST）。
Proxy-Authenticate = #challenge
WWW-Authenticateとは異なり、Proxy-Authenticateヘッダフィールドは、レスポンスチェーン上の次のアウトバウンドクライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが、認証に必要な認証情報を持っている可能性が高いためです。ただし、大企業ネットワーク内のオフィスおよび地域キャッシングプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、ユーザーエージェントによって認証情報が生成され、消費されるまで階層を通じて渡されることが一般的です。したがって、このような構成では、各プロキシが同じチャレンジセットを送信するため、Proxy-Authenticateが転送されているように見えます。
WWW-Authenticateの解析に関する考慮事項は、このヘッダフィールドにも適用されることに注意してください。詳細については、セクション11.6.1を参照してください。
11.7.2. Proxy-Authorization
「Proxy-Authorization」ヘッダフィールドにより、クライアントは、認証を必要とするプロキシに対して自身（またはそのユーザー）を識別できます。その値は、プロキシおよび/またはリクエストされているリソースのレルムに対するクライアントの認証情報を含む認証情報で構成されます。
Proxy-Authorization = credentials
Authorizationとは異なり、Proxy-Authorizationヘッダフィールドは、Proxy-Authenticateヘッダフィールドを使用して認証を要求した次のインバウンドプロキシにのみ適用されます。チェーン内で複数のプロキシが使用される場合、Proxy-Authorizationヘッダフィールドは、認証情報を受信することを期待していた最初のインバウンドプロキシによって消費されます。プロキシが特定のリクエストを協力して認証するメカニズムである場合、プロキシはクライアントリクエストから次のプロキシに認証情報を中継してもかまいません（MAY）。
11.7.3. Proxy-Authentication-Info
「Proxy-Authentication-Info」レスポンスヘッダフィールドは、プロキシ認証（セクション11.3）に適用され、そのセマンティクスが対応するリクエストのProxy-Authorizationヘッダフィールド（セクション11.7.2）によって示される認証スキームによって定義されることを除いて、Authentication-Infoと同等です：
Proxy-Authentication-Info = #auth-param
ただし、Authentication-Infoとは異なり、Proxy-Authentication-Infoヘッダフィールドは、レスポンスチェーン上の次のアウトバウンドクライアントにのみ適用されます。これは、特定のプロキシを選択したクライアントのみが、認証に必要な認証情報を持っている可能性が高いためです。ただし、大企業ネットワーク内のオフィスおよび地域キャッシングプロキシなど、同じ管理ドメイン内で複数のプロキシが使用される場合、ユーザーエージェントによって認証情報が生成され、消費されるまで階層を通じて渡されることが一般的です。したがって、このような構成では、各プロキシが同じフィールド値を送信するため、Proxy-Authentication-Infoが転送されているように見えます。
Proxy-Authentication-Infoは、認証スキームで明示的に許可されている場合、メッセージ本文が送信されることが明らかになったら、トレーラフィールド（セクション6.5）として送信できます。