diff options
Diffstat (limited to 'files/zh-tw/web/http/authentication/index.html')
| -rw-r--r-- | files/zh-tw/web/http/authentication/index.html | 123 |
1 files changed, 123 insertions, 0 deletions
diff --git a/files/zh-tw/web/http/authentication/index.html b/files/zh-tw/web/http/authentication/index.html new file mode 100644 index 0000000000..2e881ea2fd --- /dev/null +++ b/files/zh-tw/web/http/authentication/index.html @@ -0,0 +1,123 @@ +--- +title: HTTP authentication +slug: Web/HTTP/Authentication +translation_of: Web/HTTP/Authentication +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">HTTP 提供一個用來存取控制及身分驗證框架. 最普遍的 HTTP 身分驗證是基於"Basic" schema. 本頁將介紹HTTP framework for authentication 以及如何限制存取你的伺服器 and HTTP "Basic" schema.</p> + +<h2 id="The_general_HTTP_authentication_framework">The general HTTP authentication framework</h2> + +<p>{{RFC("7235")}} 定義了HTTP 身分驗證框架，它可以被使用於server to {{glossary("challenge")}} a client request 以及 client 提供身分驗證資訊. The challenge and response flow works like this: The server responds to a client with a {{HTTPStatus("401")}} (Unauthorized) response status and provides information on how to authorize with a {{HTTPHeader("WWW-Authenticate")}} response header containing at least one challenge. A client that wants to authenticate itself with a server can then do so by including an {{HTTPHeader("Authorization")}} request header field with the credentials. Usually a client will present a password prompt to the user and will then issue the request including the correct <code>Authorization</code> header.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p> + +<p>In the case of a "Basic" authentication like shown in the figure, the exchange <strong>must</strong> happen over an HTTPS (TLS) connection to be secure.</p> + +<h3 id="Proxy_authentication">Proxy authentication</h3> + +<p>The same challenge and response mechanism can be used for <em>proxy authentication</em>. In this case, it is an intermediate proxy that requires authentication. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is {{HTTPStatus("407")}} (Proxy Authentication Required), the {{HTTPHeader("Proxy-Authenticate")}} response header contains at least one challenge applicable to the proxy, and the {{HTTPHeader("Proxy-Authorization")}} request header is used for providing the credentials to the proxy server.</p> + +<h3 id="Access_forbidden">Access forbidden</h3> + +<p>If a (proxy) server receives valid credentials that are not adequate to gain access for a given resource, the server should respond with the {{HTTPStatus("403")}} <code>Forbidden</code> status code. Unlike {{HTTPStatus("401")}} <code>Unauthorized</code> or {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, authentication is impossible for this user.</p> + +<p> </p> + +<h3 id="Authentication_of_cross-origin_images">Authentication of cross-origin images</h3> + +<p>A potential security hole that has recently been fixed by browsers is authentication of cross-site images. From <a href="/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs ({{bug(1423146)}}), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.</p> + +<h3 id="Character_encoding_of_HTTP_authentication">Character encoding of HTTP authentication</h3> + +<p>Browsers use <code>utf-8</code> encoding for usernames and passwords. Firefox used to use <code>ISO-8859-1</code>, but changed over to <code>utf-8</code> for parity with other browsers, and to avoid potential problems as described in {{bug(1419658)}}.</p> + +<p> </p> + +<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers"><code>WWW-Authenticate</code> and <code>Proxy-Authenticate</code> headers</h3> + +<p>The {{HTTPHeader("WWW-Authenticate")}} and {{HTTPHeader("Proxy-Authenticate")}} response headers define the authentication method that should be used to gain access to a resource. They need to specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. The syntax for these headers is the following:</p> + +<pre class="syntaxbox">WWW-Authenticate: <type> realm=<realm> +Proxy-Authenticate: <type> realm=<realm> +</pre> + +<p>Here, <code><type></code> is the authentication scheme ("Basic" is the most common scheme and <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">introduced below</a>). The <em>realm</em> is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.</p> + +<h3 id="Authorization_and_Proxy-Authorization_headers"><code>Authorization</code> and <code>Proxy-Authorization</code> headers</h3> + +<p>The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.</p> + +<pre class="syntaxbox">Authorization: <type> <credentials> +Proxy-Authorization: <type> <credentials> +</pre> + +<h3 id="Authentication_schemes">Authentication schemes</h3> + +<p>The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.</p> + +<p>The most common authentication scheme is the "Basic" authentication scheme which is introduced in more details below. IANA maintains a <a class="external external-icon" href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">list of authentication schemes</a>, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:</p> + +<ul> + <li><strong>Basic</strong> (see {{rfc(7617)}}, base64-encoded credentials. See below for more information.),</li> + <li><strong>Bearer</strong> (see {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources),</li> + <li><strong>Digest</strong> (see {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support),</li> + <li><strong>HOBA</strong> (see {{rfc(7486)}} (draft), <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based),</li> + <li><strong>Mutual</strong> (see <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>),</li> + <li> + <p><strong>AWS4-HMAC-SHA256</strong> (see <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a>).</p> + </li> +</ul> + +<h2 id="Basic_authentication_scheme">Basic authentication scheme</h2> + +<p>The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.</p> + +<h3 id="Security_of_basic_authentication">Security of basic authentication</h3> + +<p>As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.</p> + +<h3 id="Restricting_access_with_Apache_and_basic_authentication">Restricting access with Apache and basic authentication</h3> + +<p>To password-protect a directory on an Apache server, you will need a <code>.htaccess</code> and a <code>.htpasswd</code> file.</p> + +<p>The <code>.htaccess</code> file typically looks like this:</p> + +<pre>AuthType Basic +AuthName "Access to the staging site" +AuthUserFile /path/to/.htpasswd +Require valid-user</pre> + +<p>The <code>.htaccess</code> file references a <code>.htpasswd</code> file in which each line contains of a username and a password separated by a colon (":"). You can not see the actual passwords as they are <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encrypted</a> (md5 in this case). Note that you can name your <code>.htpasswd</code> file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to <code>.ht*</code> files).</p> + +<pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. +user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ +</pre> + +<h3 id="Restricting_access_with_nginx_and_basic_authentication">Restricting access with nginx and basic authentication</h3> + +<p>For nginx, you will need to specify a location that you are going to protect and the <code>auth_basic</code> directive that provides the name to the password-protected area. The <code>auth_basic_user_file</code> directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.</p> + +<pre>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">Access using credentials in the URL</h3> + +<p>Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:</p> + +<pre class="example-bad">https://username:password@www.example.com/</pre> + +<p><strong>The use of these URLs is deprecated</strong>. In Chrome, the <code>username:password@</code> part in URLs is even<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7"> stripped out</a> for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you."</p> + +<h2 id="See_also">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> |