HTTP认证包含BASIC认证（基本认证），DIGEST认证（摘要认证）等。下面具体介绍BASIC认证（基本认证），DIGEST认证（摘要认证），SSL客户端认证，FormBase认证（基于表单认证）。
1、BASIC认证（基本认证）
认证步骤：
步骤一：客户端发送一个请求到服务器，请求资源。当请求的资源需要BASIC认证时，服务器会返回一个带WWW-Authenticate首部字段的响应，并且返回401 Authorization Required。WWW-Authenticate字段包含认证的方式（BASIC）及请求URI安全域字符串（realm）。
步骤二：客户端接收到状态码401的响应后，就会将需要的认证信息（用户ID和密码等）发送给服务器。这个认证需要以用户ID：密码的格式，并且进行base64编码处理，将处理后的字符串写入首部Authorization，然后发送请求。
步骤三：服务器接收到包含Authorization字段的请求后，会对信息进行验证。通过验证则返回一开始希望请求的资源。
缺点：用户ID和密码采用base64编码，并不安全，被盗的可能性很高。另外，如果在认证之后，想再进行一次BASIC认证，一般的浏览器无法实现认证注销操作。因此BASIC认证不常用。
2、DIGEST认证（摘要认证）
DIGEST认证使用质询/响应的方式，但它不同于BASIC认证那样直接发送明文密码，而是发送响应摘要和响应码。
质询/响应方式：一方发送请求，另一方要求认证并且返回一个质询码，请求方从质询码中计算出响应码，然后发送给响应方。
认证步骤：
步骤一：客户端发送请求，如果该资源需要认证，服务器返回带WWW-Authenticate首部字段的响应，并且返回401 Authorization Required状态码。其中WWW-Authenticate字段必须包含Request-URI安全域字符串realm和临时质询码nonce这两个信息，还应有认证的方式（DIGEST）。质询码是一种，每次随返回的401响应生成的任意随机字符串。
步骤二：客户端接收到401状态码的响应后，则会根据质询码进行MD5 计算，生成响应码，然后整合信息到Authorization首部字段，发送请求。其中Authorization必须包含username（realm限定范围内可进行认证的用户名），realm（响应中获取），nonce（响应中获取），uri（Request-URI的值，为了防止经代理转发后被修改，提前复制一份），response（经过MD5计算的密码字符串）字段信息。
步骤三：服务器接收到包含Authorization首部的报文后，进行验证，认证通过则返回一开始请求（Request-URI）的资源。并且会在Authentication-Info字段写入一些认证成功的信息。
缺点：虽然DIGEST提供密码保护机制，但是仍然存在用户伪装的危险，因此也不常用。
3、SSL客户端认证
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。它主要是避免用户ID和密码被盗取，第三者冒充登录的情况，使用的前提是客户端必须安装证书。
认证步骤：
步骤一：客户端发送请求，如果该资源需要认证，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
步骤二：用户选择要发送的客户端证书，并把客户端证书信息以Client Certificate报文方式发送给服务器。
步骤三：服务器接收客户端证书，并且验证。验证通过后领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
缺点：使用客户端证书需要支付一定的费用。认证了客户端计算机，至于是不是本人，还需要配合密码。
4、FormBase认证（基于表单认证）
FormBase认证是在提供的用户界面输入账号密码等登录信息后，发送给Web应用程序，基于认证结果来判断认证是否成功。
表单认证的一般规范是：使用Cookie来管理Session（会话）。
http是无状态协议，不会保留之前已认证成功的用户状态，因此利用Cookie来管理Session。
Session管理及Cookie状态管理步骤：
步骤一：用户在表单中输入用户ID和密码，然后将登陆信息放入报文实体的部分，通常以post的方法发送请求给服务器。其中HTML表单界面的显示和用户输入数据的发送是使用HTTPS通信。
步骤二：服务器发放用于识别用户的Session ID。对登陆信息中的账号密码进行身份验证，然后把认证状态和Session ID绑定，记录在服务器端。服务器返回响应，会在首部Set-Cookie字段中写入Session ID，提醒用户在下次请求时在请求头部携带Cookie。
步骤三：客户端接收到返回的Session ID后，会将其作为Cookie保存在本地，下次发送请求时，会自动发送Cookie。
双因素验证：SSL客户端证书用来认证客户端计算机；密码用来确定这是用户本人的行为。
5、Cookie
Cookie的工作原理
客户端第一次发送验证信息给服务器，服务器发放一个Session ID，然后将认证状态和Session ID 绑定在服务器。服务器返回一个响应，该响应有一个Set-Cookie字段包含Session ID，提示客户端存储，并且之后每次发送针对该服务器的请求都要带上包含Session ID的Cookie字段。服务器通过Session ID辨认客户端，并且返回对应的资源。
HttpOnly属性
Cookie中的数据是以名/值对形式存储，javascript可以使用document.cookie来操作Cookie。
而如果在Cookie中设置了HttpOnly（对大小写不敏感）属性，那么js就不能读取Cookie，这样可以减轻跨站脚本攻击（XSS），但不能根本解决，因为在发送请求时，请求头会携带Cookie。
Set-Cookie: username=zsx;path=/;domain=.mshanzi.com;expires=2018/10/20; HttpOnlyCookie与同源策略
同源策略需要的是协议，域名和端口都要相同。在非同源下，请求不能正常发送，cookie、localStorage和indexDB无法读取，DOM无法获得。
浏览器根据Set-Cookie创建了一个Cookie后，在每一个针对该网站的请求时，如果符合设定条件(domain和path)，都会在Header中带着这个Cookie，对于不符合条件的及其他网站的请求Cookie不会跟着发送。
参考：
《图解HTTP》--上野 宣