HTTP 認証

RFC 7235 は、サーバーがクライアントのリクエストをチャレンジし、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。

チャレンジとレスポンスの流れは以下のようになります。

1. サーバーは少なくとも 1 回のチャレンジで、クライアントに 401 (Unauthorized) レスポンスステータスを返し、 WWW-Authenticate レスポンスヘッダーを含めて認証方法に関する情報を提供します。
2. そのサーバーで自身を認証したいクライアントは、 Authorization リクエストヘッダーフィールドに資格情報を含めることでそれを行うことができます。
3. 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。

上記の全体的なメッセージの流れは、（すべてではありませんが）多くの認証方式で同じです。 ヘッダーに含まれる実際の情報とそのエンコード方法は変わります。

プロキシー認証にも同じチャレンジとレスポンスのメカニズムを使用することができます。 リソース認証とプロキシー認証の両方が共存できるように、別なヘッダーとステータスコードのセットが必要です。プロキシーの場合、チャレンジのステータスコードは 407 (Proxy Authentication Required) であり、 Proxy-Authenticate レスポンスヘッダーにプロキシーで受け付けるためのチャレンジを 1 つ以上設定します。プロキシーサーバーに資格情報を伝えるには、 Proxy-Authorization リクエストヘッダーが使用されます。

（プロキシー）サーバーが無効な資格情報を受け取った場合、 401 Unauthorized または 407 Proxy Authentication Required で応答する必要があり、ユーザーは新しいリクエストを送ったり、 Authorization ヘッダーフィールドを置き換えたりすることができます。

（プロキシー）サーバーが、有効であるが指定されたリソースにアクセスする要件を満たさない資格情報を受け取った場合、サーバーは 403 Forbidden ステータスコードを返す必要があります。 401 Unauthorized または 407 Proxy Authentication Required とは異なり、このユーザーとブラウザーは再試行することができません。

どの場合でも、サーバーは 404 Not Found ステータスコードを返すことで、十分な権限がない、または正しく認証されていないユーザーからページの存在を隠すことができます。

（ブラウザーで修正された）潜在的なセキュリティホールとして、サイトをまたいだ画像の認証があります。 Firefox 59 以降、異なるオリジンから現在の文書に読み込まれる画像リソースは、 HTTP 認証ダイアログを起動することができなくなり (Firefox バグ 1423146)、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。

ブラウザーはユーザー名とパスワードに utf-8 エンコーディングを使用します。

Firefox は ISO-8859-1 を使用していましたが、他のブラウザーとの互換性のために utf-8 に変更され、 Firefox バグ 1419658 で説明されているような潜在的な問題を回避します。

WWW-Authenticate および Proxy-Authenticate レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。どの認証方式を使用するかを指定するため、認証を希望するクライアントは資格情報の提供方法を知ることができます。

これらのヘッダーの構文は以下の通りです。

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

ここで、 <type> は認証方式です ("Basic" は最も一般的な方式であり、以下で紹介します)。 realm は保護された領域を説明するため、または保護の範囲を示すために使用されます。これは、「ステージングサイトへのアクセス」などのようなメッセージにすることができ、それによってユーザーが、どの領域にアクセスしようとしているかを知ることができます。

Authorization および Proxy-Authorization リクエストヘッダーには、（プロキシー）サーバーがユーザーエージェントを認証する資格情報が入ります。ここでは、 <type> が再び必要となり、その後に使用される認証方式によって符号化または暗号化された資格情報が続きます。

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。方式はセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。

IANA は認証方式の一覧を管理していますが、 Amazon AWS などのホストサービスが提供する他の方式もあります。一般的な認証方式には次のものがあります。

よく使われる認証方式には次のようなものがあります。

Basic

RFC 7617 を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。

Bearer

RFC 6750 を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラートークンです。

Digest

RFC 7616 を参照。 Firefox 93 以降は SHA-256 アルゴリズムに対応しています。以前のバージョンでは MD5 ハッシュだけに対応していまました（非推奨）。

HOBA

RFC 7486 3 章を参照、 HTTP オリジン認証 (HTTP Origin-Bound Authentication)、電子署名ベース

Mutual

RFC 8120 を参照

Negotiate / NTLM

RFC4599 を参照

VAPID

RFC 8292 を参照

SCRAM

RFC 7804 を参照

AWS4-HMAC-SHA256

AWS docs を参照。この方式は AWS3 サーバー認証に使用されています。

方式は、セキュリティの強さや、クライアントまたはサーバーソフトウェアで利用可能かどうかが異なります。

"Basic" 認証方式はセキュリティが非常に弱いのですが、広く対応されており、セットアップが簡単です。 以下で詳しく説明します。

"Basic" HTTP 認証方式は RFC 7617 で定義されており、資格情報を送信するのに、ユーザー ID とパスワードの組を base64 を使用してエンコードします。

ユーザー ID とパスワードは、ネットワークを介してクリアテキストとして渡されるため（base64 でエンコードされますが、 base64 は可逆エンコードです）、 Basic 認証方式は安全ではありません。 Basic 認証と組み合わせて HTTPS/TLS を使用する必要があります。これらの追加のセキュリティ強化機能がない場合は、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。

Apache サーバー上のディレクトリをパスワードで保護するには、 .htaccess ファイルと .htpasswd ファイルが必要です。

.htaccess ファイルは通常、次のようになります。

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

.htaccess ファイルは .htpasswd ファイルを参照しており、このファイルの各行にはユーザー名とパスワードをコロン (:) で区切って記述されています。実際のパスワードは（この場合は MD5 ベースのハッシュを使用して）ハッシュ化されているので表示できません。なお、必要に応じて .htpasswd ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないようにしてください。（Apache は通常 .ht* ファイルへのアクセスを禁止するように構成されています）。

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する auth_basic ディレクティブを指定する必要があります。auth_basic_user_file ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む .htpasswd ファイルを指します。

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。

https://username:password@www.example.com/

これらの URL の使用は推奨されていません。 Chrome ではセキュリティ上の理由から、URL の username:password@ 部分が削除されます。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「www.example.com というサイトに username というユーザー名でログインしようとしていますが、このウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407