. HTTP Basic
客户端以“ : ”连接用户名和密码后，再经BASE64加密通过Authorization请求头发送该密文至服务端进行验证，每次请求都需要重复发送该密文。可见Basic认证过程简单，安全性也低，存在泄露个人账号信息以及其他诸多安全问题。以下仅为原理演示，不代表真实情况：
客户端向服务器请求数据:
GET / HTTP/1.1
Host: www.myrealm.com服务端向客户端发送验证请求401：
HTTP/1.1 401 Unauthorised
Server: bfe/1.0.8.18
WWW-Authenticate: Basic realm="myrealm.com"
Content-Type: text/html; charset=utf-8客户端收到401返回值后，将自动弹出一个登录窗口，等待用户输入用户名和密码
将“用户名:密码”进行BASE64加密后发送服务端进行验证：
GET / HTTP/1.1
Host: www.myrealm.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx服务端取出Authorization请求头信息进行解密，并与用户数据库进行对比判断是否合法，合法将返回200 OK，至于是否发送Authentication-Info头部则是可选的
1 <?php 2 if (!isset($_SERVER['PHP_AUTH_USER'])) { 3 header('WWW-Authenticate: Basic realm="My Realm"'); 4 header('HTTP/1.0 401 Unauthorized'); 5 echo 'Text to send if user hits Cancel button'; 6 exit; 7 } else { 8 echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>"; 9 echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>"; 10 }
二. Digest 认证
Digest认证试图解决Basic认证的诸多缺陷而设计，用户密码在整个认证过程中是个关键性要素。
下为服务端发送的Digest认证响应头部实例及各字段含义说明：PHP官方文档中发送WWW-Authenticate头部时各字段之间用了空格，在Chrome下是不会弹出认证对话框的，应该换成”, “或”,“
WWW-Authenticate:Digest realm="Restricted area", qop="auth,auth-int", nonce="58e8e52922398", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", algorithm="MD5"
WWW-Authenticate：服务端发送的认证质询头部
Authorization-Info：服务端发送的认证响应头部，包含nextnonce、rspauth响应摘要等
qop：质量保护，其值可为auth或auth-int，auth-int包含对实体主体做完整性校验
nonce：服务端产生的随机数，用于服务端对客户端的确认，防止重放攻击。RFC2617建议采用这个随机数计算公式：nonce = BASE64(time-stamp MD5(time-stamp “:” ETag “:” private-key))，服务端可以决定这种nonce时间有效性，ETag(URL对应的Entity Tag，在CGI编程中通常需要自行生成ETag和鉴别，用于标示URL对象是否改变，区分不同语言、Session、Cookie等)可以防止对已更新资源版本(未更新无效，故需要考虑有效期)的重放请求，private-key为服务端私有key
opaque：这是一个不透明的数据字符串，在盘问中发送给客户端，客户端会将这个数据字符串再发送回服务端器。如果需要在服务端和客户端之间维护一些状态，可以用这个参数传送状态给客户端。
algorithm：摘要算法，目前支持MD5、MD5-sess
下为客户端发送的Digest认证头请求部实例及各字段含义说明：
Authorization:Digest username="somename", realm="Restricted area", nonce="58e8e52922398", uri="/t.php", response="9c839dde909d270bc5b901c7f80f77d5", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", qop="auth", nc=00000001, cnonce="9c30405c3a67a259"
cnonce：客户端产生的随机数，用于客户端对服务器的确认
nc：当服务端开启qop时，客户端才需要发送nc(nonce-count)。服务端能够通过维护nc来检测用当前nonce标记的请求重放。如果相同的nc出现在用当前nonce标记的两次请求中，那么这两次请求即为重复请求。所以对于防止重放攻击而言，除了nonce之外，nc才是最后的保证。因此nonce、nc是服务端需要维护的状态数据，故Digest认证不适合做无状态认证。
下面将就摘要计算方法进行说明：
算法的一般性表示
H(data) = MD5(data) KD(secret, data) = H(concat(secret, ":", data))
与安全信息相关的数据secret用A1表示，则
a) 采用MD5算法： A1=(user):(realm):(password) b) 采用MD5-sess算法： A1=H((user):(realm):(password)):nonce:cnonce
与安全信息无关的数据data用A2表示，则
a) QoP为auth或未定义： A2=(request-method):(uri-directive-value) b) QoP为auth-int： A2=(request-method):(uri-directive-value):H((entity-body))
摘要值用response表示，则
a) 若qop没有定义： response=H(H(A1):<nonce>:H(A2)) b) 若qop为auth或auth-int: response=H(H(A1):<nonce>:<nc>:<cnonce>:<qop>:H(A2))
http://www.cnblogs.com/XiongMaoMengNan/p/6671206.html
