2. アクセス認証フレームワーク (Access Authentication Framework)

2.1 チャレンジとレスポンス (Challenge and Response)

HTTP は、サーバーがクライアントのリクエストに対してチャレンジするため、およびクライアントが認証情報を提供するために使用できる、単純なチャレンジ-レスポンス認証フレームワークを提供する。これは、認証スキームを識別する手段として大文字小文字を区別しないトークンを使用し、その後にそのスキームによる認証を達成するために必要な追加情報が続く。後者は、カンマ区切りのパラメーターのリストか、base64 でエンコードされた情報を保持できる単一の文字シーケンスのいずれかとすることができる。

認証パラメーターは name=value の組であり、name トークンは大文字小文字を区別せずに照合され、各パラメーター名は 1 つのチャレンジにつき 1 回だけ出現しなければならない (MUST)。

auth-scheme = token

auth-param = token BWS "=" BWS ( token / quoted-string )

token68 = 1*( ALPHA / DIGIT /
             "-" / "." / "_" / "~" / "+" / "/" ) *"="

token68 構文は、66 個の非予約 URI 文字 ([RFC3986]) に加えていくつかの文字を許容するため、パディングの有無にかかわらず、base64、base64url (URL およびファイル名として安全なアルファベット)、base32、または base16 (16 進数) のエンコーディングを保持できるが、空白は除外する ([RFC4648])。

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 ヘッダーフィールドを含めることによってそうすることができる。

Authorization フィールド値と Proxy-Authorization フィールド値の両方は、(おそらくは過去のある時点で) 応答で受信したチャレンジに基づいて、要求されているリソースの realm に対するクライアントの資格情報を含む。これらの値を作成する際、ユーザーエージェントは、自身が理解する中で最も安全と考える auth-scheme のチャレンジを選択し、必要に応じてユーザーから資格情報を取得することによって作成することが望ましい。ヘッダーフィールド値の中で資格情報を送信することは、6.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) ステータスコード ([RFC7231] の 6.5.3 節) で応答することが望ましい。

HTTP は、アクセス認証のためにアプリケーションをこの単純なチャレンジ-レスポンスフレームワークに制限しない。トランスポートレベルでの認証やメッセージカプセル化による認証など、追加のメカニズムを使用でき、認証情報を指定する追加のヘッダーフィールドを伴うこともできる。ただし、そのような追加のメカニズムは本仕様では定義されない。

2.2 保護空間 (Realm)

"realm" 認証パラメーターは、保護の範囲を示したいと望む認証スキームが使用するために予約されている。

保護空間は、アクセスされているサーバーの正規ルート URI (実効リクエスト URI の scheme および authority コンポーネント。[RFC7230] の 5.5 節を参照) と、存在する場合は realm 値との組み合わせによって定義される。これらの realm により、サーバー上の保護されたリソースを、それぞれが独自の認証スキームおよび/または認可データベースを持つ保護空間の集合に分割できる。realm 値は一般にオリジンサーバーによって割り当てられる文字列であり、認証スキームに固有の追加の意味論を持つことができる。応答は、同じ auth-scheme だが異なる realm を持つ複数のチャレンジを持つことができることに注意されたい。

保護空間は、資格情報を自動的に適用できるドメインを決定する。以前のリクエストが認可されている場合、ユーザーエージェントは、認証スキーム、パラメーター、および/またはユーザー設定 (設定可能な無操作タイムアウトなど) によって決定される期間、その保護空間内の他のすべてのリクエストに対して同じ資格情報を再利用してもよい (MAY)。認証スキームによって特に許可されていない限り、単一の保護空間はそのサーバーの範囲を超えて広がることはできない。

歴史的な理由により、送信者は quoted-string 構文のみを生成しなければならない (MUST)。受信者は、長い間両方の記法を受け入れてきた既存のクライアントとの最大限の相互運用性のために、token と quoted-string の両方の構文をサポートしなければならない場合がある。

---