RFC 2617 - HTTP認証: 基本認証とダイジェストアクセス認証
発行日: 1999年6月
ステータス: 標準化過程
著者: J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart
廃止: RFC 2069
廃止者: RFC 7235, RFC 7615, RFC 7616, RFC 7617
概要 (Abstract)
「HTTP/1.0」には、基本アクセス認証方式 (Basic Access Authentication Scheme) の仕様が含まれています。この方式は、ユーザー名とパスワードがネットワーク上で平文として渡されるため、(SSLなどの外部セキュアシステムと組み合わせて使用しない限り) 安全なユーザー認証方法とは見なされていません。
本文書は、HTTPの認証フレームワーク (Authentication Framework)、オリジナルの基本認証方式、および「ダイジェストアクセス認証」(Digest Access Authentication) と呼ばれる暗号学的ハッシュに基づく方式の仕様も提供します。したがって、RFC 2069の置き換えとしても機能することを意図しています。RFC 2069で指定されたいくつかのオプション要素は、発行後に発見された問題のため、本仕様から削除されました。互換性のために他の新しい要素が追加されましたが、これらの新しい要素はオプションとされていますが、強く推奨されます。
基本認証と同様に、ダイジェストアクセス認証 (Digest Access Authentication) は、通信の両当事者が共有秘密 (パスワード) を知っていることを検証します。基本認証とは異なり、この検証はパスワードを平文で送信せずに実行できます。これは基本認証の最大の弱点です。他のほとんどの認証プロトコルと同様に、最大のリスク源は通常、コアプロトコル自体ではなく、その使用に関するポリシーと手順にあります。
本メモのステータス (Status of this Memo)
本文書は、インターネットコミュニティのためのインターネット標準化過程プロトコルを規定し、改善のための議論と提案を求めます。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1) の最新版を参照してください。本メモの配布は無制限です。
目次 (Table of Contents)
- 1. アクセス認証 (Access Authentication)
- 1.1 HTTP/1.1仕様への依存
- 1.2 アクセス認証フレームワーク
- 2. 基本認証方式 (Basic Authentication Scheme)
- 3. ダイジェストアクセス認証方式 (Digest Access Authentication Scheme)
- 3.1 序論
- 3.1.1 目的
- 3.1.2 全体的な動作
- 3.1.3 ダイジェスト値の表現
- 3.1.4 制限事項
- 3.2 ダイジェストヘッダーの仕様
- 3.2.1 WWW-Authenticateレスポンスヘッダー
- 3.2.2 Authorizationリクエストヘッダー
- 3.2.3 Authentication-Infoヘッダー
- 3.3 ダイジェスト操作
- 3.4 セキュリティプロトコル交渉
- 3.5 例
- 3.6 プロキシ認証とプロキシ承認
- 3.1 序論
- 4. セキュリティに関する考慮事項 (Security Considerations)
- 4.1 基本認証を使用したクライアントの認証
- 4.2 ダイジェスト認証を使用したクライアントの認証
- 4.3 限定使用のnonce値
- 4.4 ダイジェスト認証と基本認証の比較
- 4.5 リプレイ攻撃
- 4.6 複数の認証方式による脆弱性
- 4.7 オンライン辞書攻撃
- 4.8 中間者攻撃
- 4.9 選択平文攻撃
- 4.10 事前計算辞書攻撃
- 4.11 バッチブルートフォース攻撃
- 4.12 偽造サーバーによるなりすまし
- 4.13 パスワードの保存
- 4.14 まとめ
- 5. サンプル実装 (Sample implementation)
- 6. 謝辞 (Acknowledgments)
- 7. 参考文献 (References)
- 8. 著者のアドレス (Authors' Addresses)
コアコンセプト
2つの認証方式
1. 基本認証 (Basic Authentication)
- 原理: ユーザー名とパスワードをBase64エンコードして送信
- 形式:
Authorization: Basic base64(username:password) - セキュリティ: ⚠️ 平文送信、安全ではない (HTTPSを使用しない限り)
- 使用例: シンプルなアプリケーション、内部システム、HTTPSと組み合わせ
2. ダイジェスト認証 (Digest Authentication)
- 原理: MD5ハッシュを使用、パスワードは平文で送信されない
- 形式: nonce、realm、qopなどのパラメータを含む
- セキュリティ: ✅ 基本認証より安全、ただしHTTPS推奨
- 使用例: より高いセキュリティが必要なHTTP認証
認証フロー
クライアント サーバー
| |
|------- 1. 保護されたリソースを ---->|
| リクエスト |
| |
|<------ 2. 401 + WWW-Authenticate --|
| (チャレンジ) |
| |
|------- 3. Authorizationヘッダー --->|
| (資格情報) |
| |
|<------ 4. 200 OK + リソース --------|
| |
HTTPステータスコード
- 401 Unauthorized: 認証が必要である
- 407 Proxy Authentication Required: プロキシ認証が必要である
主要なHTTPヘッダー
WWW-Authenticate: サーバーが送信するチャレンジAuthorization: クライアントが送信する資格情報Authentication-Info: 任意である認証情報Proxy-Authenticate: プロキシサーバーからのチャレンジProxy-Authorization: プロキシに送信する資格情報
例
基本認証の例
サーバーレスポンス:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WallyWorld"
クライアントリクエスト:
GET /private/index.html HTTP/1.1
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
ダイジェスト認証の例
サーバーレスポンス:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
クライアントリクエスト:
GET /dir/index.html HTTP/1.1
Authorization: Digest username="Mufasa",
realm="[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
関連リソース
- 公式原文: RFC 2617 (TXT)
- 公式ページ: RFC 2617 DataTracker
- 廃止: RFC 2069
- 廃止者:
- RFC 7235 (HTTP/1.1 Authentication)
- RFC 7615 (HTTP Authentication-Info)
- RFC 7616 (HTTP Digest Access Authentication)
- RFC 7617 (HTTP Basic Authentication)
セキュリティ警告 ⚠️
- 基本認証は安全ではない: HTTPSと組み合わせて使用しなければならない
- ダイジェスト認証にも制限がある: 基本認証より優れているが、HTTPSは依然として推奨される
- 現代的な代替手段: OAuth 2.0、JWTなどの現代的な認証メカニズムの使用を検討すべきである
- パスワードの保存: サーバーはソルト付きハッシュを使用してパスワードを保存すべきである
重要な注意事項: RFC 2617はRFC 7235、7616、7617などによって廃止されました。現代のアプリケーションは、これらの更新された標準を参照するか、OAuth 2.0などの現代的な認証フレームワークを使用すべきです。