HTTP API 认证授权术

sername 和 password 来进行登录。整个过程被定义在了 RFC 2617 中，也被描述在了 Wikipedia: Basic Access Authentication 词条中，同时也可以参看 MDN HTTP Authentication

其技术原理如下：

1. 把 username和 password 做成 username:password 的样子(用冒号分隔)
2. 进行 Base64 编码。Base64("username:password") 得到一个字符串(如：把 haoel:coolshell 进行 base64 后可以得到 aGFvZW86Y29vbHNoZWxsCg )
3. 把 aGFvZW86Y29vbHNoZWxsCg 放到 HTTP 头中 Authorization 字段中，形成 Authorization: Basic aGFvZW86Y29vbHNoZWxsCg，然后发送到服务端。
4. 服务端如果没有在头里看到认证字段，则返回 401 错，以及一个个 WWW-Authenticate: Basic Realm='HelloWorld' 之类的头要求客户端进行认证。之后如果没有认证通过，则返回一个 401 错。如果服务端认证通过，那么会返回 200。

我们可以看到，使用 Base64 的目的无非就是为了把一些特殊的字符给搞掉，这样就可以放在 HTTP 协议里传输了。而这种方式的问题最大的问题就是把用户名和口令放在网络上传，所以，一般要配合 TLS/SSL 的安全加密方式来使用。我们可以看到 JIRA Cloud 的 API 认证支持HTTP Basic 这样的方式。

但我们还是要知道，这种把用户名和密码同时放在公网上传输的方式有点不太好，因为 Base64 不是加密协议，而是编码协议，所以就算是有 HTTPS 作为安全保护，给人的感觉还是不放心。

Digest Access

中文称“HTTP 摘要认证”，最初被定义在了 RFC 2069 文档中(后来被 RFC 2617 引入了一系列安全增强的选项;“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数)。

其基本思路是，请求方把用户名口令和域做一个 MD5 – MD5(username:realm:password) 然后传给服务器，这样就不会在网上传用户名和口令了，但是，因为用户名和口令基本不会变，所以，这个 MD5 的字符串也是比较固定的，因此，这个认证过程在其中加入了两个事，一个是 nonce 另一个是 qop

• 首先，调用方发起一个普通的 HTTP 请求。比如：GET /coolshell/admin/ HTTP/1.1 服务端自然不能认证能过，服务端返回 401 错误，并且在 HTTP 头里的 WWW-Authenticate 包含如下信息：

（编辑：四平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!