| HTTP／HTTPS |
| --- |
|  |
| 版本 |
| * HTTP/0.9
* HTTP/1.0
* HTTP/1.1
* HTTP/2
* HTTP/3
 |
| 请求方法 |
| * OPTIONS
* GET
* HEAD
* POST
* PUT
* DELETE
* TRACE
* CONNECT
* PATCH
 |
| 报文主体 |
| 頭欄位 |
| * Cookie
* ETag
* Location
* HTTP referer
* DNT
* X-Forwarded-For
 |
| 狀態碼 |
| * 301 Moved Permanently
* 302 Found
* 303 See Other
* 307 Temporary Redirect
* 403 Forbidden
* 404 Not Found
* 451 Unavailable For Legal Reasons
 |
| 
相关主题 |
| * HTTP持久连接
* HTTP压缩
* 分块传输编码
* WWW
 |
| * 
* 论
* 编
 |

在HTTP中，**基本认证**（英語：）是允许http用户代理（如：网页浏览器）在请求时，提供 用户名 和 口令 的一种方式。

在进行基本认证的过程里，请求的HTTP头字段会包含`Authorization`字段，形式如下： `Authorization: Basic <凭证>`，该凭证是用户和密码的组和的base64编码。

最初，基本认证是定义在HTTP 1.0规范（RFC 1945）中，后续的有关安全的信息可以在HTTP 1.1规范（RFC 2616）和HTTP认证规范（RFC 2617）中找到。于1999年 RFC 2617 过期，于2015年的 RFC 7617 重新被定义。

在MDN网站，已经有对应的维基文章。

优点
--

HTTP基本认证 是一种十分简单的技术，使用的是 HTTP头部字段 强制用户访问网络资源，而不是通过必要的cookie、会话ID、登录页面等（非获取访问控制的）手段。

基本上所有流行的网页浏览器都支持基本认证。基本认证很少在可公开访问的互联网网站上使用，有时候会在小型私有系统中使用（如路由器网页管理接口）。之后诞生的 HTTP摘要认证 用于替代基本认证，允许密钥以相对安全的方式在不安全的通道上传输。

程序员和系统管理员有时会在可信网络环境中使用基本认证。由于，基本认证使用的是Base64，可解码成明文，因此使用Telnet等网络协议工具进行监视时，可以直接获取内容，并用于诊断。

缺点
--

基本认证 并没有为传送凭证（英語：）提供任何机密性的保护。仅仅使用 Base64 编码并传输，而没有使用任何 加密 或 散列算法。因此，基本认证常常和 HTTPS 一起使用，以提供机密性。

现存的浏览器保存认证信息直到标签页或浏览器被关闭，或者用户清除历史记录。HTTP没有为服务器提供一种方法指示客户端丢弃这些被缓存的密钥。这意味着服务器端在用户不關閉瀏覽器的情況下，並没有一种有效的方法来让用户登出。

同时 HTTP 并没有提供登出机制。但是，在一些浏览器上，存在清除凭证（credentials ）缓存的方法。

原理
--

### 文字过程

这一个典型的HTTP客户端和HTTP服务器的对话，服务器安装在同一台计算机上（localhost），包含以下步骤：

1. 客户端请求一个需要身份认证的页面，但是没有提供用户名和口令。这通常是用户在地址栏输入一个URL，或是打开了一个指向该页面的链接。
2. 服务端响应一个401应答码，并提供一个认证域（英語：），头部字段为：`WWW-Authenticate`，该字段为要求客户端提供适配的资源。 `WWW-Authenticate: Basic realm="Secure Area"` 该例子，`Basic` 为验证的模式，`realm="Secure Area"`为保护域，用于与其他请求URI作区别。
3. 接到应答后，客户端显示该认证域给用户并提示输入用户名和口令。此时用户可以选择确定或取消。
4. 用户输入了用户名和口令后，客户端软件将对其进行处理，并在原先的请求上增加认证消息头（英語：）然后重新发送再次尝试。过程如下：
	1. 将用户名和口令拼接为`用户：密码`形式的字符串。
	2. 如果服务器`WWW-Authenticate`字段有指定编码，则将字符串编译成对应的编码（如：UTF-8）。
	3. 将字符串编码为base64。
	4. 拼接`Basic` ，放入`Authorization`头字段，就像这样：`Authorization Basic 字符串`。 示例：用户名：`Aladdin` ，密码：`OpenSesame` ，拼接后为`Aladdin:OpenSesame`，编码后`QWxhZGRpbjpPcGVuU2VzYW1l`，在HTTP头部里会是这样：`Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l`。 Base64编码并非加密算法，其无法保证安全与隐私，仅用于将用户名和口令中的不兼容的字符转换为均与HTTP协议兼容的字符集。
5. 在本例中，服务器接受了该认证屏幕并返回了页面。如果用户凭据非法或无效，服务器可能再次返回401应答码，客户端可以再次提示用户输入口令。

**注意:**客户端有可能不需要用户交互，在第一次请求中就发送认证消息头。

### 电文过程

#### 1.客户端请求（没有认证信息）

```
GET /private/index.html HTTP/1.0
Host: localhost

```

（跟随一个换行，以回车（CR）加换行（LF）的形式）

#### 2.服务端应答

```
HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </HEAD>
  <BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>
```

#### 3.客户端请求（有认证信息）

用户名"Aladdin"，口令 "open sesame"

```
GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

```

（跟随一个空行，如上所述）

Authorization消息头的用户名和口令的值可以容易地编码和解码。

#### 4.服务端的应答

```
HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476

```

（跟随一个空行，随后是需凭据页的HTML文本）。

参考文献和注释
-------

1. ↑ . MDN Web 文档.  [2020-01-29]. （原始内容存档于2020-04-14） （中文）.
2. ↑  这里的"所有的流行网页浏览器"包括任何目前市场份额超过0.2%的网页浏览器，参见网页浏览器比较了解网页浏览器对HTTP的支持
3. ↑ .  [2010-07-10]. （原始内容存档于2010-05-26）.
4. ↑ . IETF: 46. May 1996  [3 February 2017]. （原始内容存档于2010-11-30）.
5. ↑  T. Fielding, Roy; Tim, Berners-Lee; Henrik, Frystyk.. tools.ietf.org.  [2020-01-28]. （原始内容存档于2020-01-25）.
6. ↑  Frystyk, Henrik.. tools.ietf.org.  [2020-01-28]. （原始内容存档于2020-04-15） （英语）.

参见
--

* HTTP摘要认证

外部链接
----

* RFC2617: HTTP Authentication: Basic and Digest Access Authentication（页面存档备份，存于）