メインコンテンツまでスキップ

1. アクセス認証 (Access Authentication)

1.1 HTTP/1.1仕様への依存 (Reliance on the HTTP/1.1 Specification)​

本仕様は、HTTP/1.1仕様 [2] の付属文書です。本仕様は、その文書のセクション2.1の拡張BNFを使用し、その文書で定義されている非終端記号とHTTP/1.1仕様の他の側面の両方に依存しています。

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

HTTPは、サーバーがクライアントリクエストをチャレンジするために使用してもよい (MAY)、およびクライアントが認証情報を提供するために使用してもよい (MAY) 単純なチャレンジ-レスポンス認証メカニズム (Challenge-Response Authentication Mechanism) を提供します。これは、認証方式 (Authentication Scheme) を識別するために拡張可能で大文字小文字を区別しないトークン (Token) を使用し、その後にコンマで区切られた属性-値のペアのリストが続き、これらのペアはその方式を介して認証を実現するために必要なパラメータを運びます。

auth-scheme    = token
auth-param     = token "=" ( token | quoted-string )

オリジンサーバー (Origin Server) は、401 (Unauthorized) レスポンスメッセージを使用してユーザーエージェントの承認をチャレンジします。このレスポンスは、要求されたリソースに適用可能な少なくとも1つのチャレンジを含む WWW-Authenticate ヘッダーフィールドを含まなければなりません (MUST)。プロキシ (Proxy) は、407 (Proxy Authentication Required) レスポンスメッセージを使用してクライアントの承認をチャレンジし、要求されたリソースに適用可能な少なくとも1つのプロキシチャレンジを含む Proxy-Authenticate ヘッダーフィールドを含まなければなりません (MUST)。

challenge   = auth-scheme 1*SP 1#auth-param

注意: WWW-Authenticate または Proxy-Authenticate ヘッダーフィールド値に複数のチャレンジが含まれている場合、または複数の WWW-Authenticate ヘッダーフィールドが提供されている場合、チャレンジの内容自体にコンマで区切られた認証パラメータのリストが含まれている可能性があるため、ユーザーエージェントは解析時に特別な注意を払わなければなりません (MUST)。

認証パラメータrealm (領域) は、すべての認証方式に対して定義されています:

realm       = "realm" "=" realm-value
realm-value = quoted-string

realm指令（大文字小文字を区別しない）は、チャレンジを発行するすべての認証方式に対して必須である (REQUIRED)。realm値（大文字小文字を区別する）は、アクセスされているサーバーの正規ルートURL（abs_pathが空のサーバーのabsoluteURI; [2]のセクション5.1.2を参照）と組み合わせて、保護空間 (Protection Space) を定義します。これらのrealmにより、サーバー上の保護されたリソースを保護空間のセットに分割でき、各空間には独自の認証方式および/または承認データベースがあります。realm値は文字列であり、通常はオリジンサーバーによって割り当てられ、認証方式固有の追加のセマンティクスを持つ場合があります。同じauth-schemeでも異なるrealmを持つ複数のチャレンジが存在する可能性があることに注意してください。

オリジンサーバーで自身を認証したいユーザーエージェント――通常は、必ずしもそうとは限りませんが、401 (Unauthorized) を受信した後――は、リクエストに Authorization ヘッダーフィールドを含めることで認証してもよい (MAY)。プロキシで自身を認証したいクライアント――通常は、必ずしもそうとは限りませんが、407 (Proxy Authentication Required) を受信した後――は、リクエストに Proxy-Authorization ヘッダーフィールドを含めることで認証してもよい (MAY)。Authorization フィールド値と Proxy-Authorization フィールド値の両方は、要求されているリソースのrealmに対するクライアントの認証情報を含む資格情報 (Credentials) で構成されます。ユーザーエージェントは、理解できる最も強力なauth-schemeのチャレンジの1つを使用することを選択しなければならず (MUST)、そのチャレンジに基づいてユーザーに資格情報を要求しなければなりません。

credentials = auth-scheme #auth-param

注意: 多くのブラウザは基本認証 (Basic Authentication) のみを認識し、最初に提示されるauth-schemeであることを要求します。サーバーは、基本認証が最低限受け入れられる標準である場合にのみ、それを含めるべきです (SHOULD)。

保護空間は、資格情報を自動的に適用できるドメインを決定します。以前のリクエストが承認されている場合、同じ資格情報は、認証方式、パラメータ、および/またはユーザー設定によって決定される期間、その保護空間内の他のすべてのリクエストで再利用してもよい (MAY)。認証方式で別途定義されていない限り、単一の保護空間はそのサーバーの範囲を超えて拡張できません。

オリジンサーバーがリクエストとともに送信された資格情報を受け入れたくない場合、401 (Unauthorized) レスポンスを返すべきです (SHOULD)。レスポンスは、要求されたリソースに適用可能な少なくとも1つの（おそらく新しい）チャレンジを含む WWW-Authenticate ヘッダーフィールドを含まなければなりません (MUST)。プロキシがリクエストとともに送信された資格情報を受け入れない場合、407 (Proxy Authentication Required) を返すべきです (SHOULD)。レスポンスは、要求されたリソースに適用可能な（おそらく新しい）チャレンジを含む Proxy-Authenticate ヘッダーフィールドを含まなければなりません (MUST)。

HTTPプロトコルは、アクセス認証にこの単純なチャレンジ-レスポンスメカニズムを使用することをアプリケーションに制限しません。トランスポート層暗号化またはメッセージカプセル化を介して、および認証情報を指定する追加のヘッダーフィールドとともに、追加のメカニズムを使用してもよい (MAY)。ただし、これらの追加のメカニズムは本仕様では定義されていません。

プロキシは、オリジンサーバーとのユーザーエージェント認証に関して完全に透過的でなければなりません (MUST)。つまり、WWW-Authenticate および Authorization ヘッダーを変更せずに転送し、[2]のセクション14.8のルールに従わなければなりません。Proxy-Authenticate および Proxy-Authorization ヘッダーフィールドの両方は、ホップバイホップヘッダー (Hop-by-Hop Headers) です（[2]のセクション13.5.1を参照）。

に最終更新