「Basic」HTTP 認証スキーム

これはインターネット標準トラック文書です。

本書はインターネット技術タスクフォース (IETF) の成果物です。IETF コミュニティの合意を示すものであり、公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 5741 のセクション 2 を参照してください。

本書の現行の状態、訂正情報（errata）、およびフィードバックの方法については http://www.rfc-editor.org/info/rfc7617 を参照してください。

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本書は、ユーザーID／パスワードの組を Base64 でエンコードして送信する "Basic" ハイパーテキスト転送プロトコル (HTTP) 認証スキームを定義します（HTTP の認証スキームは [RFC7235] に定義されています）。

このスキームは、ユーザーIDとパスワードがネットワーク上で平文に渡されるため、TLS（Transport Layer Security、[RFC5246]）のような外部の安全なシステムと併用しない限り、安全なユーザー認証手段とは見なされません。

「Basic」スキームは以前 Section 2 の [RFC2617] で定義されていました。本書はその定義を更新し、'charset' 認証パラメータ（セクション 2.1）を導入して国際化に関する問題にも対処します。

RFC 2617 を更新する他の文書には、認証フレームワークを定義する "Hypertext Transfer Protocol (HTTP/1.1): Authentication"（[RFC7235]）、"Digest" スキームの定義を更新する "HTTP Digest Access Authentication"（[RFC7616]）、および "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields"（[RFC7615]）があります。これら 4 つの文書を合わせて RFC 2617 は廃止されます。

Basic 認証スキームは、クライアントが各保護領域（"realm"）に対してユーザーIDとパスワードで自身を認証する必要があるというモデルに基づいています。realm 値はサーバー内で等価比較のみ可能なフリーフォーム文字列です。サーバーは要求されたリソースに適用される保護領域に対してユーザーIDとパスワードを検証できる場合にのみリクエストを処理します。

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

チャレンジでは：

• スキーム名は "Basic" です。
• 認証パラメータ 'realm' は REQUIRED です（[RFC7235]、Section 2.2）。
• 認証パラメータ 'charset' は OPTIONAL です（セクション 2.1 を参照）。
• 他の認証パラメータは定義されていません — 未知のパラメータは受信側で MUST 無視されるべきであり、新しいパラメータは本仕様の改訂によってのみ定義できます。

また、チャレンジの正しい解析の複雑さについては Section 4.1 を参照してください（[RFC7235]）。

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

資格情報には、Section 2.1 に定義された "token68" 構文が使用されます（[RFC7235]）。値は以下に定義されるように user-id とパスワードに基づいて計算されます。

保護領域内の URI に対して資格情報が欠けたリクエストを受け取った場合、サーバーは 401 (Unauthorized) ステータスコードと WWW-Authenticate ヘッダーフィールドを用いたチャレンジで応答できます（[RFC7235]、Section 3.1、Section 4.1）。

例えば：

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

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

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

認可を受け取るために、クライアントは次の操作を行います：

1. ユーザーから user-id とパスワードを取得する、
2. user-id、単一のコロン (":")、パスワード を連結して user-pass を構築する、
3. user-pass をオクテット列にエンコードする（文字エンコーディング方式の議論は下記参照）、
4. そしてそのオクテット列を Base64（[RFC4648]、Section 4）でエンコードして US-ASCII 文字列列（[RFC0020]）に変換して basic-credentials を得る。

この認証スキームの元の定義では、user-pass をオクテット列に変換するための文字エンコーディング方式が指定されていませんでした。実務では多くの実装がロケール固有のエンコーディング（例えば ISO-8859-1）や UTF-8 を選びました。後方互換性の理由から、本仕様は US-ASCII と互換（任意の US-ASCII 文字が対応する US-ASCII 文字コードと一致する単一オクテットにマップされる）である限り、デフォルトのエンコーディングを未定義のままにします。

user-id とパスワードは制御文字を含んではならない（"CTL" を参照、Appendix B.1 の定義）ことに注意してください。

さらに、user-id にコロン文字が含まれると無効です。user-pass 文字列では最初のコロンが user-id とパスワードの区切りになるため、最初のコロン以降のテキストはパスワードの一部と見なされます。コロンを含む user-id は user-pass 文字列にエンコードできません。

多くのユーザーエージェントはユーザーが入力した user-id にコロンが含まれていないかを検査せずに user-pass を生成することがあり、その場合受信側は username の一部をパスワードの一部として扱います。

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

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

US-ASCII 以外の文字を含む user-id やパスワードは、通信する両当事者がどの文字エンコーディング方式を使用するかに合意していない限り相互運用性の問題を引き起こします。サーバーは新しい 'charset' パラメータ（セクション 2.1）を使って "UTF-8" を優先することを示し、クライアントがそのエンコーディングに切り替える可能性を高めることができます。

'realm' パラメータはテキスト的なデータを運ぶことがあり得ますが、[RFC7235] は非 US-ASCII 文字を確実に輸送する方法を定義していません。これは既知の問題であり、その仕様の改訂で対処される必要があります。

Basic 認証スキームは安全なユーザー認証手段ではなく、エンティティは物理ネットワーク上で平文として送信されます。HTTP は Basic 認証に一回限りのパスワードを使用するなどの拡張を追加することを妨げるものではありません。

Basic 認証の最も重大な欠陥は、ユーザーのパスワードが物理ネットワーク上で平文送信されることです。多くの他の認証スキームはこの問題に対処しています。

パスワードが平文送信されるため、Basic 認証は HTTPS（[RFC2818]）のような強化がない限り、機密性の高い情報保護には 使用すべきではありません。

Basic 認証の一般的な用途は識別目的です — 例えばサーバー上の利用状況統計を正確に収集するためにユーザーに user-id とパスワードを提供させる場合などです。この用途では、サーバーがユーザーに user-id とパスワードの両方を発行し、ユーザーにパスワード選択を許さない場合にのみ危険が少ないと考えられます。危険は、ユーザーが複数のパスワードを管理する手間を避けるために同じパスワードを使い回すことが多い点に起因します。

サーバーがユーザーにパスワード選択を許す場合、脅威はサーバー上の文書への不正アクセスだけでなく、ユーザーが同じパスワードで保護している他のシステムへの不正アクセスにも及びます。さらに、サーバーのパスワードデータベースに保存された多くのパスワードは他サイトでのユーザーのパスワードである可能性があり、これが流出すればプライバシーとセキュリティの両方の問題を引き起こします（[RFC6973]）。

Basic 認証は偽のサーバーによる詐取にも脆弱です。ユーザーが保護されたホストに接続していると誤認させられると、攻撃者はパスワードを要求して保存し、後で使用するために偽のエラーを返すことができます。サーバー実装者はこの種の詐取に対して防御すべきです。特に既存の接続上でメッセージフレーミングを乗っ取れるソフトウェアコンポーネントは慎重に、あるいはまったく使用しないべきです（例：[RFC3875] の NPH スクリプト）。

Basic 認証を実装するサーバーやプロキシはリクエストを認証するために何らかの形でユーザーパスワードを保存する必要があります。これらのパスワードは、流出時に容易に復元されないような方法で保存されるべきです。ユーザーが自分でパスワードを設定できる場合、ユーザーは弱いパスワードを選び使い回す傾向があるため特に重要です。本書では最新のパスワードハッシュ手法の詳細には踏み込みませんが、サーバー運用者はユーザーのリスクを最小化する努力をすべきです。例えば平文やソルトなしのダイジェストでの保存は避けるべきです。現代のパスワードハッシュ手法については "Password Hashing Competition" を参照してください（<https://password-hashing.net>）。

UTF-8 の使用と正規化は追加のセキュリティ上の考慮事項を導入します。詳細は RFC3629 Section 10 および RFC5198 Section 6 を参照してください。

IANA は "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"（[RFC7235]）を <http://www.iana.org/assignments/http-authschemes> で管理しています。

"Basic" 認証スキームのエントリは本仕様を参照するように更新されています。

スキームの定義は [RFC7235] のような新しい仕様に整合するよう書き直されました。

新しい認証パラメータ 'charset' が追加されました。これは助言的なものであるため、既存の実装は変更を必ずしも必要としませんが、新しい情報を利用したい場合は採用できます。

本仕様は以前 RFC 2617 で定義されていた "Basic" HTTP 認証スキームの定義を引き継ぎます。本仕様のテキストの大部分は当該仕様から引用されています。John Franks、Phillip M. Hallam-Baker、Jeffery L. Hostetler、Scott D. Lawrence、Paul J. Leach、Ari Luotonen、Lawrence C. Stewart の作業に感謝します。詳細は RFC2617 Section 6 を参照してください。

user-pass に使用される文字エンコーディング方式に関する国際化問題は 2000 年に Mozilla のバグとして報告されました（<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> および <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>）。この問題に対処するために新しい auth-param を導入するというアイデアは Andrew Clover によるものです。

HTTPAUTH ワーキンググループのメンバーおよびその他のレビューア（Stephen Farrell、Roy Fielding、Daniel Kahn Gillmor、Tony Hansen、Bjoern Hoehrmann、Kari Hurtta、Amos Jeffries、Benjamin Kaduk、Michael Koeller、Eric Lawrence、Barry Leiba、James Manger、Alexey Melnikov、Kathleen Moriarty、Juergen Schoenwaelder、Yaron Sheffer、Meral Shirazipour、Michael Sweet、Martin Thomson）に感謝します。