From 094e49f2dbbf37f73312be261d74cd3a0e05fcb7 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Sat, 19 Feb 2022 23:09:20 +0900 Subject: 2022/01/22 時点の英語版に同期 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../authentication/http-auth-sequence-diagram.png | Bin 0 -> 11059 bytes files/ja/web/http/authentication/index.md | 193 ++++++++++++--------- 2 files changed, 109 insertions(+), 84 deletions(-) create mode 100644 files/ja/web/http/authentication/http-auth-sequence-diagram.png diff --git a/files/ja/web/http/authentication/http-auth-sequence-diagram.png b/files/ja/web/http/authentication/http-auth-sequence-diagram.png new file mode 100644 index 0000000000..143c48ea3e Binary files /dev/null and b/files/ja/web/http/authentication/http-auth-sequence-diagram.png differ diff --git a/files/ja/web/http/authentication/index.md b/files/ja/web/http/authentication/index.md index bc7bb26fee..c9d9f137e9 100644 --- a/files/ja/web/http/authentication/index.md +++ b/files/ja/web/http/authentication/index.md @@ -2,143 +2,168 @@ title: HTTP 認証 slug: Web/HTTP/Authentication tags: - - Access Control - - Authentication - - Guide + - アクセス制御 + - 認証 + - ガイド - HTTP - - Security - - アクセス制限 - セキュリティ - - 認証 translation_of: Web/HTTP/Authentication --- -
{{HTTPSidebar}}
+{{HTTPSidebar}} + +HTTP はアクセス制御と認証の基本的な枠組みを提供しています。 +このページでは、 HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。 + +## 一般的な HTTP 認証の枠組み + +{{RFC("7235")}} は、サーバーがクライアントのリクエストを{{glossary("challenge", "チャレンジ")}}し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。 + +チャレンジとレスポンスの流れは以下のようになります。 + +1. サーバーは少なくとも 1 回のチャレンジで、クライアントに {{HTTPStatus("401")}} (Unauthorized) レスポンスステータスを返し、 {{HTTPHeader("WWW-Authenticate")}} レスポンスヘッダーを含めて認証方法に関する情報を提供します。 +2. そのサーバーで自身を認証したいクライアントは、 {{HTTPHeader("Authorization")}} リクエストヘッダーフィールドに資格情報を含めることでそれを行うことができます。 +3. 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい `Authorization` ヘッダーを含むリクエストを発行します。 + +![クライアントとサーバーのライフライン間の HTTP メッセージを説明するシーケンス図。](http-auth-sequence-diagram.png) -

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

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

一般的な HTTP 認証の枠組み

+> **Warning:** 上記の図で使用されている "Basic" 認証方式は、資格情報をエンコードしますが暗号化はしません。 +> これは安全な接続 (HTTPS/TLS) を介して行わなければ完全に安全ではありません。 -

{{RFC("7235")}} は、サーバーがクライアント要求を {{glossary("challenge")}} し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。

+### プロキシー認証 -

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

+*プロキシー認証*にも同じチャレンジとレスポンスのメカニズムを使用することができます。 +リソース認証とプロキシー認証の両方が共存できるように、別なヘッダーとステータスコードのセットが必要です。プロキシーの場合、チャレンジのステータスコードは {{HTTPStatus("407")}} (Proxy Authentication Required) であり、 {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーにプロキシーで受け付けるためのチャレンジを 1 つ以上設定します。プロキシーサーバーに資格情報を伝えるには、 {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーが使用されます。 -
    -
  1. サーバーは少なくとも１回のチャレンジで、クライアントに {{HTTPStatus("401")}} (Unauthorized) レスポンスステータスを返し、 {{HTTPHeader("WWW-Authenticate")}} レスポンスヘッダーを含めて認証方法に関する情報を提供します。
    2. -
  2. サーバーで自身を認証したいクライアントは {{HTTPHeader("Authorization")}} リクエストヘッダフィールドに資格情報を含めることでそれを行うことができます。
    3. -
  3. 通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい Authorization ヘッダーを含むリクエストを発行します。
    4. -
+### アクセスの不許可 -

クライアントとサーバーのライフライン間の HTTP メッセージを説明するシーケンス図。

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

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

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

プロキシ認証

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

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

+### オリジン間の画像の認証 -

アクセスの不許可

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

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

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

オリジン間の画像の認証

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

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

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

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

+### WWW-Authenticate および Proxy-Authenticate ヘッダー -

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

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

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

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

WWW-Authenticate および Proxy-Authenticate ヘッダー

+```http +WWW-Authenticate: realm= +Proxy-Authenticate: realm= +``` -

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

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

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

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

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

+```http +Authorization: +Proxy-Authorization: +``` -

Authorization および Proxy-Authorization ヘッダー

+## 認証方式 -

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

+一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。方式はセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。 -
Authorization: <type> <credentials>
-Proxy-Authorization: <type> <credentials>
-
+IANA は[認証方式の一覧](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml)を管理していますが、 Amazon AWS などのホストサービスが提供する他の方式もあります。一般的な認証方式には次のものがあります。 -

認証方式

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

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

+- **Basic** + - : {{rfc(7617)}} を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。 +- **Bearer** + - : {{rfc(6750)}} を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラートークンです。 +- **Digest** + - : {{rfc(7616)}} を参照。 Firefox 93 以降は SHA-256 暗号化に対応しています。以前のバージョンでは MD5 ハッシュだけに対応していまました（非推奨）。 +- **HOBA** + - : {{rfc(7486)}} 3 章を参照、 HTTP オリジン認証 (**H**TTP **O**rigin-**B**ound **A**uthentication)、電子署名ベース +- **Mutual** + - : {{rfc(8120)}} を参照 +- **Negotiate** / **NTLM** + - : [RFC4599](https://www.ietf.org/rfc/rfc4559.txt) を参照 +- **VAPID** + - : {{rfc(8292)}} を参照 +- **SCRAM** + - : {{rfc(7804)}} を参照 +- **AWS4-HMAC-SHA256** + - : [AWS docs](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html) を参照。この方式は AWS3 サーバー認証に使用されています。 -

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

+方式は、セキュリティの強さや、クライアントまたはサーバーソフトウェアで利用可能かどうかが異なります。 -
-
Basic
-
{{rfc(7617)}} を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。
-
Bearer
-
{{rfc(6750)}} を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラトークンです。
-
Digest
-
{{rfc(7616)}} を参照。 Firefox では md5 ハッシュだけに対応しています。 SHA 暗号化の対応については {{bug(472823)}} を参照。
-
HOBA
-
{{rfc(7486)}} 3章 を参照、HTTP オリジン認証 (HTTP Origin-Bound Authentication)、電子署名ベース
-
Mutual
-
{{rfc(8120)}} を参照
-
AWS4-HMAC-SHA256
-
AWS docs を参照
-
+"Basic" 認証方式はセキュリティが非常に弱いのですが、広く対応されており、セットアップが簡単です。 +以下で詳しく説明します。 -

Basic 認証方式

+## Basic 認証方式 -

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

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

Basic 認証の安全性

+### Basic 認証の安全性 -

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

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

Apache と Basic 認証によるアクセス制限

+### Apache と Basic 認証によるアクセス制限 -

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

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

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

+`.htaccess` ファイルは通常、次のようになります。 -
AuthType Basic
+```
+AuthType Basic
 AuthName "Access to the staging site"
 AuthUserFile /path/to/.htpasswd
-Require valid-user
+Require valid-user +``` -

.htaccess ファイルは .htpasswd ファイルを参照し、各行にはユーザー名とパスワードをコロン (":") で区切って記述します。実際のパスワードは暗号化されている (この場合は md5) ので表示できません。必要に応じて .htpasswd ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないように注意してください。(Apache は通常 .ht* ファイルへのアクセスを禁止するように設定されています)。

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

nginx と Basic 認証によるアクセス制限

+### nginx と Basic 認証によるアクセス制限 -

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

+nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する `auth_basic` ディレクティブを指定する必要があります。`auth_basic_user_file` ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む `.htpasswd` ファイルを指します。 -
location /status {
+```
+location /status {
     auth_basic           "Access to the staging site";
     auth_basic_user_file /etc/apache2/.htpasswd;
-}
+} +``` -

URL 内の認証情報を使用したアクセス

+### URL 内の認証情報を使用したアクセス -

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

+多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。 -
https://username:password@www.example.com/
+```example-bad +https://username:password@www.example.com/ +``` -

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

+**これらの URL の使用は推奨されていません。** +Chrome ではセキュリティ上の理由から、URL の `username:password@` 部分が[削除されます](https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7)。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「“www\.example\.com” というサイトに “username” というユーザー名でログインしようとしていますが、このウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。 -

関連情報

+## 関連情報 -
    -
  • {{HTTPHeader("WWW-Authenticate")}}
    • -
  • {{HTTPHeader("Authorization")}}
    • -
  • {{HTTPHeader("Proxy-Authorization")}}
    • -
  • {{HTTPHeader("Proxy-Authenticate")}}
    • -
  • {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}
    • -
+- {{HTTPHeader("WWW-Authenticate")}} +- {{HTTPHeader("Authorization")}} +- {{HTTPHeader("Proxy-Authorization")}} +- {{HTTPHeader("Proxy-Authenticate")}} +- {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}} -- cgit v1.2.3-54-g00ecf