HTTP 認証

HTTP はアクセス制御と認証の基本的な枠組みを提供しています。最も一般的な HTTP 認証は、"Basic" 認証に基づいています。このページでは、HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。

一般的な HTTP 認証の枠組み

RFC 7235 は、サーバーがクライアント要求を challenge し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義します。チャレンジとレスポンスの流れは以下のようになります：サーバーは少なくとも１回目の challenge でクライアントに 401 (Unauthorized) レスポンスステータスを返し、WWW-Authenticate レスポンスヘッダーを含めて認証方法を提供します。サーバーで自身を認証したいクライアントは Authorization リクエストヘッダフィールドにクレデンシャルを含めることでそれを行うことができます。通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。

A sequence diagram illustrating HTTP messages between a client and a server lifeline.

図に示すような "Basic" 認証の場合、やり取りを安全に行うために HTTPS (TLS) 接続を介して行われなければなりません。

プロキシ認証

プロキシ認証にも同じチャレンジとレスポンスのメカニズムを使用できます。この場合、認証を必要とする中間プロキシです。リソース認証とプロキシ認証の両方が共存できるため、異なるヘッダーとステータスコードのセットが必要です。プロキシの場合、チャレンジしているステータスコードは 407 (Proxy Authentication Required) で、Proxy-Authenticate レスポンスヘッダはプロキシサーバーに資格情報を提供するために、Proxy-Authorization リクエストヘッダーが使用されます。

アクセスの不許可

特定のリソースにアクセスするのに十分ではないが有効な資格情報を (プロキシ) サーバーが受け取った場合、サーバーは 403 Forbidden ステータスコードでレスポンスする必要があります。401 Unauthorized または 407 Proxy Authentication Required とは異なり、このユーザーは認証できません。

オリジン間の画像の認証

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

HTTP 認証の文字エンコーディング

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

`WWW-Authenticate` 及び `Proxy-Authenticate` ヘッダー

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

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

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

Authorization and Proxy-Authorization headers

Authorization と Proxy-Authorization リクエストヘッダーには、(プロキシ) サーバーを持つ User agent を認証するための認証情報が含まれています。ここでは、タイプが再び必要となり、その後にどの認証方式が使用されるかに応じて符号化または暗号化されることができるクレデンシャルが続きます。

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

認証方式

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

最も一般的な認証方式は "Basic" 認証方式であり、これについては以下で詳しく説明します。IANA は認証スキームのリストを管理していますが、Amazon AWS などのホストサービスが提供する他のスキームもあります。一般的な認証方式には次のものがあります。

Basic (RFC 7617、base64 でコード化された認証情報を参照),
Bearer (RFC 6750、OAuth 2.0 で保護されたリソースにアクセスするベアラトークンを参照),
Digest (RFC 7616を参照、Firefox では md5 ハッシュだけがサポートされています。SHA 暗号化のサポートについてはバグ 472823 を参照),
HOBA (RFC 7486 3章を参照、HTTP オリジン認証 (HTTP Origin-Bound Authentication)、デジタル署名ベース),
Mutual ( RFC 8120 を参照),
AWS4-HMAC-SHA256 (AWS docs を参照).

Basic 認証方式

"Basic" HTTP 認証方式は RFC 7617 で定義されており、Base64 を使用してエンコードされたユーザー ID とパスワードのペアとしてクレデンシャルを送信します。

Basic 認証の安全性

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

Apache 及び 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 及び Basic 認証によるアクセス制限

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 内の認証情報を使用したアクセス

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

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

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