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

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)


コアコンセプト

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)

セキュリティ警告 ⚠️

  1. 基本認証は安全ではない: HTTPSと組み合わせて使用しなければならない
  2. ダイジェスト認証にも制限がある: 基本認証より優れているが、HTTPSは依然として推奨される
  3. 現代的な代替手段: OAuth 2.0、JWTなどの現代的な認証メカニズムの使用を検討すべきである
  4. パスワードの保存: サーバーはソルト付きハッシュを使用してパスワードを保存すべきである

重要な注意事項: RFC 2617はRFC 7235、7616、7617などによって廃止されました。現代のアプリケーションは、これらの更新された標準を参照するか、OAuth 2.0などの現代的な認証フレームワークを使用すべきです。