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

2. 'Basic' 認証スキーム

Basic 認証スキームは、クライアントが各保護空間 ("realm") に対してユーザー ID とパスワードで自身を認証する必要があるというモデルに基づいています。realm 値は自由形式の文字列であり、そのサーバー上の他の realm との等価性のみ比較できます。サーバーは、要求されたリソースに適用される保護空間のユーザー ID とパスワードを検証できる場合にのみ、要求を処理します。

Basic 認証スキームは、認証フレームワークを次のように利用します。

チャレンジでは:

  • スキーム名は "Basic" です。
  • 認証パラメータ 'realm' は必須 (REQUIRED) です ([RFC7235]、第 2.2 節)。
  • 認証パラメータ 'charset' は任意 (OPTIONAL) です (第 2.1 節を参照)。
  • 他の認証パラメータは定義されていません —— 受信者は未知のパラメータを無視しなければならず (MUST)、新しいパラメータはこの仕様を改訂することによってのみ定義できます。

また、チャレンジを適切に解析する複雑さについて議論している [RFC7235] の第 4.1 節も参照してください。

スキーム名とパラメータ名の両方が大文字小文字を区別せずにマッチされることに注意してください。

認証情報には、[RFC7235] の第 2.1 節で定義されている "token68" 構文が使用されます。値は、以下で定義されているようにユーザー ID とパスワードに基づいて計算されます。

認証情報を欠く保護空間内の URI への要求を受信すると、サーバーは 401 (Unauthorized) ステータスコード ([RFC7235]、第 3.1 節) と WWW-Authenticate ヘッダーフィールド ([RFC7235]、第 4.1 節) を使用してチャレンジで応答できます (can)。

例えば:

HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"

ここで "WallyWorld" は、サーバーが保護空間を識別するために割り当てた文字列です。

プロキシは、407 (Proxy Authentication Required) ステータスコード ([RFC7235]、第 3.2 節) と Proxy-Authenticate ヘッダーフィールド ([RFC7235]、第 4.3 節) を使用して同様のチャレンジで応答できます。

認可を受けるために、クライアントは次のことを行います:

  1. ユーザーからユーザー ID とパスワードを取得します、
  2. ユーザー ID、単一のコロン (":") 文字、パスワードを連結して user-pass を構築します、
  3. user-pass をオクテットシーケンスにエンコードします (文字エンコーディング方式の議論については以下を参照)、
  4. このオクテットシーケンスを Base64 ([RFC4648]、第 4 節) を使用して US-ASCII 文字のシーケンス ([RFC0020]) にエンコードすることで basic-credentials を取得します。

この認証スキームの元の定義は、user-pass をオクテットシーケンスに変換するために使用される文字エンコーディング方式を指定できていませんでした。実際には、ほとんどの実装は ISO-8859-1 ([ISO-8859-1]) などのロケール固有のエンコーディング、または UTF-8 ([RFC3629]) のいずれかを選択しました。下位互換性の理由から、この仕様は US-ASCII と互換性がある限り (任意の US-ASCII 文字を US-ASCII 文字コードに一致する単一のオクテットにマッピングする)、デフォルトのエンコーディングを未定義のままにし続けます。

ユーザー ID とパスワードは、制御文字を含んではなりません (MUST NOT) ([RFC5234] の附属書 B.1 の "CTL" を参照)。

さらに、コロン文字を含むユーザー ID は無効です。user-pass 文字列の最初のコロンがユーザー ID とパスワードを互いに分離するためです。最初のコロンの後のテキストはパスワードの一部です。コロンを含むユーザー ID は user-pass 文字列にエンコードできません。

多くのユーザーエージェントは、ユーザーが提供したユーザー ID にコロンが含まれていないかをチェックせずに user-pass 文字列を生成することに注意してください。受信者は、ユーザー名入力の一部をパスワードの一部として扱います。

ユーザーエージェントがユーザー ID "Aladdin" とパスワード "open sesame" を送信したい場合、次のヘッダーフィールドを使用します:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

2.1. 'charset' 認証パラメータ​

チャレンジにおいて、サーバーは 'charset' 認証パラメータを使用して、"user-pass" (オクテットのシーケンス) を生成する際にユーザーエージェントが使用することを期待する文字エンコーディング方式を示すことができます。この情報は純粋に助言的なものです。

許可される値は "UTF-8" のみです。大文字小文字を区別せずにマッチさせる必要があります ([RFC2978]、第 2.3 節を参照)。これは、サーバーが文字データを Unicode 正規化形式 C ("NFC"; [RFC5198] の第 3 節を参照) に変換し、UTF-8 文字エンコーディング方式 ([RFC3629]) を使用してオクテットにエンコードすることを期待していることを示します。

ユーザー ID については、受信者はコロン (":") 文字を除き、[RFC7613] の第 3.3 節で定義されている "UsernameCasePreserved" プロファイルで定義されているすべての文字をサポートしなければなりません (MUST)。

パスワードについては、受信者は [RFC7613] の第 4.2 節で定義されている "OpaqueString" プロファイルで定義されているすべての文字をサポートしなければなりません (MUST)。

他の値は将来の使用のために予約されています。

注意: 'charset' はチャレンジでのみ定義されています。Basic 認証は認証情報に単一のトークン ('token68' 構文) を使用するため、認証情報の構文は拡張可能ではありません。

注意: 名前 'charset' は [RFC2831] の第 2.1.1 節との一貫性のために選択されました。より良い名前は 'accept-charset' だったでしょう。これは、それが現れるメッセージについてではなく、サーバーの期待についてだからです。

以下の例では、サーバーは Basic 認証を使用して "foo" realm で認証を求め、UTF-8 文字エンコーディング方式を優先しています:

WWW-Authenticate: Basic realm="foo", charset="UTF-8"

パラメータ値はトークンまたは引用文字列のいずれかであることに注意してください。この場合、サーバーは引用文字列表記法の使用を選択しました。

ユーザーの名前は "test" で、パスワードは文字列 "123" の後に Unicode 文字 U+00A3 (POUND SIGN) が続きます。文字エンコーディング方式 UTF-8 を使用すると、user-pass は次のようになります:

't' 'e' 's' 't' ':' '1' '2' '3' pound
74  65  73  74  3A  31  32  33  C2  A3

このオクテットシーケンスを Base64 ([RFC4648]、第 4 節) でエンコードすると、次のようになります:

dGVzdDoxMjPCow==

したがって、Authorization ヘッダーフィールドは次のようになります:

Authorization: Basic dGVzdDoxMjPCow==

または、プロキシ認証の場合:

Proxy-Authorization: Basic dGVzdDoxMjPCow==

2.2. 認証情報の再利用​

認証されたリクエストの絶対 URI ([RFC3986]、第 4.3 節) が与えられた場合、そのリクエストの認証スコープは、パスコンポーネント ("hier_part"; [RFC3986]、第 3 節を参照) の最後のスラッシュ ("/") 文字の後のすべての文字を削除することによって取得されます。クライアントは、認証スコープのプレフィックスマッチを持つ URI によって識別されるリソースも、その認証されたリクエストの realm 値によって指定された保護空間内にあると仮定すべきです (SHOULD)。

クライアントは、サーバーから別のチャレンジを受信することなく、その空間内のリソースのリクエストで対応する Authorization ヘッダーフィールドを事前に送信してもよい (MAY) です。同様に、クライアントがプロキシにリクエストを送信する場合、プロキシサーバーから別のチャレンジを受信することなく、Proxy-Authorization ヘッダーフィールドでユーザー ID とパスワードを再利用してもよい (MAY) です。

例えば、次のような認証されたリクエストが与えられた場合:

http://example.com/docs/index.html

以下の URI へのリクエストは既知の認証情報を使用できます:

http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1

一方、以下の URI は:

http://example.com/other/
https://example.com/docs/

認証スコープの外にあると見なされます。

URI は複数の認証スコープの一部になる可能性があることに注意してください ("http://example.com/" や "http://example.com/docs/" など)。この仕様では、これらのどれをより高い優先度で扱うべきかは定義していません。

に最終更新