2022/01/22 時点の英語版に同期

2 files changed, 109 insertions, 84 deletions

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
--- /dev/null
+++ b/files/ja/web/http/authentication/http-auth-sequence-diagram.png
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
 ---
-<div>{{HTTPSidebar}}</div>
+{{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)
 
-<p class="summary"><span class="seoSummary">HTTP はアクセス制御と認証の基本的な枠組みを提供しています。このページでは、HTTP の認証の枠組みを紹介し、サーバーで HTTP の "Basic" 認証を使用してアクセスを制限する方法を紹介します。</span></p>
+上記の全体的なメッセージの流れは、（すべてではありませんが）多くの[認証方式](#認証方式)で同じです。
+ヘッダーに含まれる実際の情報とそのエンコード方法は変わります。
 
-<h2 id="The_general_HTTP_authentication_framework" name="The_general_HTTP_authentication_framework">一般的な HTTP 認証の枠組み</h2>
+> **Warning:** 上記の図で使用されている "Basic" 認証方式は、資格情報をエンコードしますが暗号化はしません。
+> これは安全な接続 (HTTPS/TLS) を介して行わなければ完全に安全ではありません。
 
-<p>{{RFC("7235")}} は、サーバーがクライアント要求を {{glossary("challenge")}} し、クライアントが認証情報を提供するために使用できる HTTP 認証フレームワークを定義しています。</p>
+### プロキシー認証
 
-<p>チャレンジとレスポンスの流れは以下のようになります。</p>
+*プロキシー認証*にも同じチャレンジとレスポンスのメカニズムを使用することができます。
+リソース認証とプロキシー認証の両方が共存できるように、別なヘッダーとステータスコードのセットが必要です。プロキシーの場合、チャレンジのステータスコードは {{HTTPStatus("407")}} (Proxy Authentication Required) であり、 {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーにプロキシーで受け付けるためのチャレンジを 1 つ以上設定します。プロキシーサーバーに資格情報を伝えるには、 {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーが使用されます。
 
-<ol>
- <li>サーバーは少なくとも１回のチャレンジで、クライアントに {{HTTPStatus("401")}} (Unauthorized) レスポンスステータスを返し、 {{HTTPHeader("WWW-Authenticate")}} レスポンスヘッダーを含めて認証方法に関する情報を提供します。</li>
- <li>サーバーで自身を認証したいクライアントは {{HTTPHeader("Authorization")}} リクエストヘッダフィールドに資格情報を含めることでそれを行うことができます。</li>
- <li>通常、クライアントはユーザーにパスワードのプロンプトを表示し、正しい <code>Authorization</code> ヘッダーを含むリクエストを発行します。</li>
-</ol>
+### アクセスの不許可
 
-<p><img alt="クライアントとサーバーのライフライン間の HTTP メッセージを説明するシーケンス図。" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;" title="Sequence Diagram of Client-server HTTP Authentication"></p>
+（プロキシー）サーバーが*無効な*資格情報を受け取った場合、 {{HTTPStatus("401")}} `Unauthorized` または {{HTTPStatus("407")}} `Proxy Authentication Required` で応答する必要があり、ユーザーは新しいリクエストを送ったり、 {{HTTPHeader("Authorization")}} ヘッダーフィールドを置き換えたりすることができます。
 
-<p>この図に示したような "Basic" 認証の場合、やり取りは安全のために HTTPS (TLS) 接続を介して<strong>行われなければなりません</strong>。</p>
+（プロキシー）サーバーが、有効であるが指定されたリソースにアクセスする要件を満たさない資格情報を受け取った場合、サーバーは {{HTTPStatus("403")}} `Forbidden` ステータスコードを返す必要があります。 {{HTTPStatus("401")}} `Unauthorized` または {{HTTPStatus("407")}} `Proxy Authentication Required` とは異なり、このユーザーとブラウザーは再試行することができません。
 
-<h3 id="Proxy_authentication" name="Proxy_authentication">プロキシ認証</h3>
+どの場合でも、サーバーは {{HTTPStatus("404")}} `Not Found` ステータスコードを返すことで、十分な権限がない、または正しく認証されていないユーザーからページの存在を隠すことができます。
 
-<p><em>プロキシ認証</em>にも同じチャレンジとレスポンスのメカニズムを使用できます。リソース認証とプロキシ認証の両方が共存できるため、異なるヘッダーとステータスコードのセットが必要です。プロキシの場合、チャレンジのステータスコードは {{HTTPStatus("407")}} (Proxy Authentication Required) で、 {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーはプロキシサーバーに資格情報を提供するために、 {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーが使用されます。</p>
+### オリジン間の画像の認証
 
-<h3 id="Access_forbidden" name="Access_forbidden">アクセスの不許可</h3>
+（ブラウザーで修正された）潜在的なセキュリティホールとして、サイトをまたいだ画像の認証があります。
+[Firefox 59](/ja/docs/Mozilla/Firefox/Releases/59) 以降、異なるオリジンから現在の文書に読み込まれる画像リソースは、 HTTP 認証ダイアログを起動することができなくなり ({{bug(1423146)}})、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。
 
-<p>特定のリソースにアクセスするのに十分ではないが有効な資格情報を (プロキシ) サーバーが受け取った場合、サーバーは {{HTTPStatus("403")}} <code>Forbidden</code> ステータスコードを返す必要があります。 {{HTTPStatus("401")}} <code>Unauthorized</code> または {{HTTPStatus("407")}} <code>Proxy Authentication Required</code> とは異なり、このユーザーは認証できません。</p>
+### HTTP 認証の文字エンコーディング
 
-<h3 id="Authentication_of_cross-origin_images" name="Authentication_of_cross-origin_images">オリジン間の画像の認証</h3>
+ブラウザーはユーザー名とパスワードに `utf-8` エンコーディングを使用します。
 
-<p>ブラウザーによって最近修正された潜在的なセキュリティホールとして、サイト間での画像の認証があります。 <a href="/ja/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> 以降、異なるオリジンから現在の文書に読み込まれる画像リソースは、 HTTP 認証ダイアログを起動することができなくなり ({{bug(1423146)}})、攻撃者が任意の画像をサードパーティ製のページに埋め込んでユーザーの認証情報を盗むことを防ぎます。</p>
+Firefox は `ISO-8859-1` を使用していましたが、他のブラウザーとの互換性のために `utf-8` に変更され、 {{bug(1419658)}} で説明されているような潜在的な問題を回避します。
 
-<h3 id="Character_encoding_of_HTTP_authentication" name="Character_encoding_of_HTTP_authentication">HTTP 認証の文字エンコーディング</h3>
+### WWW-Authenticate および Proxy-Authenticate ヘッダー
 
-<p>ブラウザーはユーザー名とパスワードに <code>utf-8</code> エンコーディングを使用します。</p>
+{{HTTPHeader("WWW-Authenticate")}} および {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。どの認証方式を使用するかを指定するため、認証を希望するクライアントは資格情報の提供方法を知ることができます。
 
-<p>Firefox は <code>ISO-8859-1</code> を使用していましたが、他のブラウザーとの互換性のために <code>utf-8</code> に変更され、 {{bug(1419658)}} で説明されているような潜在的な問題を回避します。</p>
+これらのヘッダーの構文は以下の通りです。
 
-<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers" name="WWW-Authenticate_and_Proxy-Authenticate_headers">WWW-Authenticate および Proxy-Authenticate ヘッダー</h3>
+```http
+WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+```
 
-<p>{{HTTPHeader("WWW-Authenticate")}} および {{HTTPHeader("Proxy-Authenticate")}} レスポンスヘッダーは、リソースへのアクセスに使用する認証メソッドを定義します。どの認証方式を使用するかを指定するため、認証を希望するクライアントは資格情報の提供方法を知ることができます。これらのヘッダーの構文は次のとおりです。</p>
+ここで、 `<type>` は認証方式です ("Basic" は最も一般的な方式であり、[以下で紹介](#basic_認証方式)します)。 *realm* は保護された領域を説明するため、または保護の範囲を示すために使用されます。これは、「ステージングサイトへのアクセス」などのようなメッセージにすることができ、それによってユーザーが、どの領域にアクセスしようとしているかを知ることができます。
 
-<p>これらのヘッダーの構文は以下の通りです。</p>
+### Authorization および Proxy-Authorization ヘッダー
 
-<pre class="syntaxbox notranslate">WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
-Proxy-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
-</pre>
+{{HTTPHeader("Authorization")}} および {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーには、（プロキシー）サーバーがユーザーエージェントを認証する資格情報が入ります。ここでは、 `<type>` が再び必要となり、その後に使用される認証方式によって符号化または暗号化された資格情報が続きます。
 
-<p>ここで、 <code>&lt;type&gt;</code> は認証スキームです ("Basic" は最も一般的なスキームであり、<a href="/ja/docs/Web/HTTP/Authentication#Basic_authentication_scheme">以下で紹介</a>します)。 <em>realm</em> は保護された領域を説明するため、または保護の範囲を示すために使用されます。これは、「ステージングサイトへのアクセス」などのようなメッセージにすることができ、それによってユーザーが、どの領域にアクセスしようとしているかを知ることができます。</p>
+```http
+Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+```
 
-<h3 id="Authorization_and_Proxy-Authorization_headers" name="Authorization_and_Proxy-Authorization_headers">Authorization および Proxy-Authorization ヘッダー</h3>
+## 認証方式
 
-<p>{{HTTPHeader("Authorization")}} および {{HTTPHeader("Proxy-Authorization")}} リクエストヘッダーには、(プロキシ) サーバーがユーザーエージェントを認証する資格情報が入ります。ここでは、 <code>&lt;type&gt;</code> が再び必要となり、その後に使用される認証方式によって符号化または暗号化された資格情報が続きます。</p>
+一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。方式はセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。
 
-<pre class="syntaxbox notranslate">Authorization: &lt;type&gt; &lt;credentials&gt;
-Proxy-Authorization: &lt;type&gt; &lt;credentials&gt;
-</pre>
+IANA は[認証方式の一覧](https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml)を管理していますが、 Amazon AWS などのホストサービスが提供する他の方式もあります。一般的な認証方式には次のものがあります。
 
-<h3 id="Authentication_schemes" name="Authentication_schemes">認証方式</h3>
+よく使われる認証方式には次のようなものがあります。
 
-<p>一般的な HTTP 認証フレームワークは、いくつかの認証方式によって使用されます。スキームはセキュリティ強度とクライアント、またはサーバーソフトウェアでの可用性が異なる場合があります。</p>
+- **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 サーバー認証に使用されています。
 
-<p>最も一般的な認証方式は "Basic" 認証方式であり、これについては以下で詳しく説明します。 IANA は<a class="external external-icon" href="https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">認証スキームの一覧</a>を管理していますが、 Amazon AWS などのホストサービスが提供する他のスキームもあります。一般的な認証方式には次のものがあります。</p>
+方式は、セキュリティの強さや、クライアントまたはサーバーソフトウェアで利用可能かどうかが異なります。
 
-<dl>
- <dt><strong>Basic</strong></dt>
- <dd>{{rfc(7617)}} を参照。 base64 でエンコードされた資格情報です。詳しくは後述します。</dd>
- <dt><strong>Bearer</strong></dt>
- <dd>{{rfc(6750)}} を参照。 OAuth 2.0 で保護されたリソースにアクセスするベアラトークンです。</dd>
- <dt><strong>Digest</strong></dt>
- <dd>{{rfc(7616)}} を参照。 Firefox では md5 ハッシュだけに対応しています。 SHA 暗号化の対応については {{bug(472823)}} を参照。</dd>
- <dt><strong>HOBA</strong></dt>
- <dd>{{rfc(7486)}} 3章 を参照、HTTP オリジン認証 (<strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication)、電子署名ベース</dd>
- <dt><strong>Mutual</strong></dt>
- <dd>{{rfc(8120)}} を参照</dd>
- <dt><strong>AWS4-HMAC-SHA256</strong></dt>
- <dd><a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a> を参照</dd>
-</dl>
+"Basic" 認証方式はセキュリティが非常に弱いのですが、広く対応されており、セットアップが簡単です。
+以下で詳しく説明します。
 
-<h2 id="Basic_authentication_scheme" name="Basic_authentication_scheme">Basic 認証方式</h2>
+## Basic 認証方式
 
-<p>"Basic" HTTP 認証方式は {{rfc(7617)}} で定義されており、Base64 を使用してエンコードされたユーザー ID とパスワードのペアとしてクレデンシャルを送信します。</p>
+"Basic" HTTP 認証方式は {{rfc(7617)}} で定義されており、資格情報を送信するのに、ユーザー ID とパスワードの組を base64 を使用してエンコードします。
 
-<h3 id="Security_of_basic_authentication" name="Security_of_basic_authentication">Basic 認証の安全性</h3>
+### Basic 認証の安全性
 
-<p>ユーザー ID とパスワードはネットワークを介してクリアテキスト (base64 でエンコードされていますが、 base64 は可逆エンコードです) として渡されるため、 Basic 認証方式は<strong>安全ではありません</strong>。 Basic 認証と組み合わせて HTTPS/TLS を使用する必要があります。これらの追加のセキュリティ強化機能がない場合は、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。</p>
+ユーザー ID とパスワードは、ネットワークを介してクリアテキストとして渡されるため（base64 でエンコードされますが、 base64 は可逆エンコードです）、 Basic 認証方式は**安全ではありません**。 Basic 認証と組み合わせて HTTPS/TLS を使用する必要があります。これらの追加のセキュリティ強化機能がない場合は、機密情報や重要な情報を保護するために Basic 認証を使用しないでください。
 
-<h3 id="Restricting_access_with_Apache_and_basic_authentication" name="Restricting_access_with_Apache_and_basic_authentication">Apache と Basic 認証によるアクセス制限</h3>
+### Apache と Basic 認証によるアクセス制限
 
-<p>Apache サーバー上のディレクトリをパスワードで保護するには、 <code>.htaccess</code> ファイルと <code>.htpasswd</code> ファイルが必要です。</p>
+Apache サーバー上のディレクトリをパスワードで保護するには、 `.htaccess` ファイルと `.htpasswd` ファイルが必要です。
 
-<p><code>.htaccess</code> ファイルは通常、次のようになります。</p>
+`.htaccess` ファイルは通常、次のようになります。
 
-<pre class="notranslate">AuthType Basic
+```
+AuthType Basic
 AuthName "Access to the staging site"
 AuthUserFile /path/to/.htpasswd
-Require valid-user</pre>
+Require valid-user
+```
 
-<p><code>.htaccess</code> ファイルは <code>.htpasswd</code> ファイルを参照し、各行にはユーザー名とパスワードをコロン (":") で区切って記述します。実際のパスワードは<a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">暗号化されている</a> (この場合は md5) ので表示できません。必要に応じて <code>.htpasswd</code> ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないように注意してください。(Apache は通常 <code>.ht*</code> ファイルへのアクセスを禁止するように設定されています)。</p>
+`.htaccess` ファイルは `.htpasswd` ファイルを参照しており、このファイルの各行にはユーザー名とパスワードをコロン (`:`) で区切って記述されています。実際のパスワードは（この場合は MD5 ベースのハッシュを使用して）[ハッシュ化されている](https://httpd.apache.org/docs/2.4/misc/password_encryptions.html)ので表示できません。なお、必要に応じて `.htpasswd` ファイルの名前を変更することができますが、このファイルには誰にもアクセスできないようにしてください。（Apache は通常 `.ht*` ファイルへのアクセスを禁止するように構成されています）。
 
-<pre class="notranslate">aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+```
+aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
 user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
-</pre>
+```
 
-<h3 id="Restricting_access_with_nginx_and_basic_authentication" name="Restricting_access_with_nginx_and_basic_authentication">nginx と Basic 認証によるアクセス制限</h3>
+### nginx と Basic 認証によるアクセス制限
 
-<p>nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する <code>auth_basic</code> ディレクティブを指定する必要があります。<code>auth_basic_user_file</code> ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む <code>.htpasswd</code> ファイルを指します。</p>
+nginx の場合は、保護する場所とパスワードで保護された領域に名前を指定する `auth_basic` ディレクティブを指定する必要があります。`auth_basic_user_file` ディレクティブは上の Apache の例のように、暗号化されたユーザー資格情報を含む `.htpasswd` ファイルを指します。
 
-<pre class="notranslate">location /status {
+```
+location /status {
     auth_basic           "Access to the staging site";
     auth_basic_user_file /etc/apache2/.htpasswd;
-}</pre>
+}
+```
 
-<h3 id="Access_using_credentials_in_the_URL" name="Access_using_credentials_in_the_URL">URL 内の認証情報を使用したアクセス</h3>
+### URL 内の認証情報を使用したアクセス
 
-<p>多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。</p>
+多くのクライアントでは次のように、ユーザー名とパスワードを含むエンコードされた URL を使用してログインプロンプトを回避できます。
 
-<pre class="example-bad notranslate">https://username:password@www.example.com/</pre>
+```example-bad
+https://username:password@www.example.com/
+```
 
-<p><strong>これらの URL の使用は推奨されていません。</strong>Chrome ではセキュリティ上の理由から、URL の <code>username:password@</code> 部分も<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7">削除されます</a>。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「"username" というユーザー名で "www.example.com" というサイトにログインしようとしていますが、ウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。</p>
+**これらの URL の使用は推奨されていません。**
+Chrome ではセキュリティ上の理由から、URL の `username:password@` 部分が[削除されます](https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7)。 Firefox ではサイトが実際に認証を要求するかどうかをチェックし、そうでない場合 Firefox はユーザーに「“www\.example\.com” というサイトに “username” というユーザー名でログインしようとしていますが、このウェブサイトは認証を必要としません。これはあなたを騙そうとしている可能性があります。」と警告します。
 
-<h2 id="See_also" name="See_also">関連情報</h2>
+## 関連情報
 
-<ul>
- <li>{{HTTPHeader("WWW-Authenticate")}}</li>
- <li>{{HTTPHeader("Authorization")}}</li>
- <li>{{HTTPHeader("Proxy-Authorization")}}</li>
- <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
- <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
-</ul>
+- {{HTTPHeader("WWW-Authenticate")}}
+- {{HTTPHeader("Authorization")}}
+- {{HTTPHeader("Proxy-Authorization")}}
+- {{HTTPHeader("Proxy-Authenticate")}}
+- {{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}