访问用户身份认证的确认有些网页只希望特定的人浏览，或者干脆只对这个人可见。为了实现这个目标，身份验证功能是必不可少的。让我们一起了解一下认证机制。1. 什么是身份验证1.计算机本身无法确定坐在显示器前的用户的身份。此外，无法确认谁在网络的另一端。可见，对方的client要想知道是谁在访问服务器，就得自己上报。不过，就算是访问服务器的对方自称是上野，身份是否属实也无从谈起。为了确认上野本人是否真的有权限进入系统，需要检查“只有注册者本人知道的信息”和“只有注册者本人才能获得的信息”。2、查看的信息通常是指：密码：只有本人知道的字符串信息。动态令牌：仅在本人持有的设备中显示的一次性密码。数字证书：仅由本人（终端）持有的信息。生物认证：指纹、虹膜等生物识别信息。IC卡等：仅限本人持有的信息。不过，即使对方是假用户，只要能通过用户验证，电脑都会默认用户的行为。因此，控制机密信息的密码绝不能被他人获取，更不能被轻易破解。HTTP使用的认证方式HTTP/1.1使用的认证方式如下。BASIC认证（basicauthentication）DIGEST认证（digestauthentication）SSL客户端认证FormBase认证（form-b??asedauthentication）此外，还有Windows统一认证（Keberosauthentication、NTLMauthentication）。2.BASIC认证BASIC认证（basicauthentication）是从HTTP/1.0开始定义的一种认证方式。即使是现在，一些网站仍然使用这种身份验证方法。它是Web服务器和通信客户端之间的一种身份验证方法。1.BASIC认证的认证步骤第一步：当请求的资源需要BASIC认证时，服务器会返回一个带有WWW-Authenticate头域的响应以及状态码401AuthorizationRequired。该字段包含身份验证方法(BASIC)和Request-URI安全域字符串（领域）。第二步：收到状态码401的客户端需要向服务器发送用户ID和密码才能通过BASIC认证。发送的字符串内容由用户ID和密码组成，由冒号（:）连接，然后进行Base64编码处理。假设用户ID是guest，密码是guest，那么串联将形成类似guest:guest的字符串。然后经过Base64编码，最后的结果就是Z3Vlc3Q6Z3Vlc3Q=。将此字符串写入头字段Authorization后，发送请求。当用户代理是浏览器时，用户只需要输入用户名和密码，浏览器就会自动完成Base64编码的转换。第三步：服务器端收到头域Authorizationrequest，会验证认证信息的正确性。如果验证通过，则返回包含Request-URI资源的响应。虽然BASIC身份验证使用Base64编码，但并未加密。它不需要任何额外的信息来解码它。也就是说，由于明文被解码为用户ID和密码，在HTTP等非加密通信线路上进行BASIC认证的过程中，如果有人窃听，被盗的可能性极高。另外，当你想再次进行BASIC认证时，一般浏览器无法实现认证注销操作，这也是问题之一。BASIC认证使用起来不够方便灵活，也达不到大多数网站所期望的安全级别，因此不常用。3. DIGEST认证为了弥补BASIC认证的弱点，从HTTP/1.1开始就有了DIGEST认证。DIGEST认证也使用挑战/响应方式（challenge/response），但不像BASIC认证那样直接发送明文密码。1、所谓质询-响应方式，就是一方会先向对方发送认证请求，然后利用对方收到的质询码计算生成响应码。最后将响应码返回给对方进行鉴权。由于只将响应摘要和质询码产生的计算结果发送给对方，与BASIC认证相比，密码泄露的可能性降低。DIGEST认证的认证步骤：第1步：当请求资源被认证时，服务器会返回一个带有WWW-Authenticate头域的响应，状态码为401AuthorizationRequired。该字段包含挑战-响应认证所需的临时挑战代码（随机数，nonce）。头域WWW-Authenticate必须包含realm和nonce信息。客户端通过将这两个值发送回服务器来进行身份验证。随机数是每次返回401响应时生成的任意随机字符串。字符串通常建议由Base64编码的十六进制数字组成，但实际内容取决于服务器的具体实现。第二步：收到401状态码的客户端返回一个响应，其中包含DIGEST认证所需的头域Authorization信息。头域Authorization必须包含username、realm、nonce、uri和response的域信息。其中realm和nonce是之前从服务器收到的响应中的字段。username是在限定的realm范围内可以认证的用户名。uri(digest-uri)是Request-URI的值，但考虑到Request-URI的值可能被proxy转发后修改，所以会提前复制一份保存在uri中。response也可以称为Request-Digest，将密码字符串进行MD5运算后存储起来，形成响应码。响应中的其他实体请参考第六章请求头域Authorization。另外Request-Digest相关的计算规则比较复杂，有兴趣的读者不妨深入研究一下RFC2617。Step3：服务器收到包含Authorization头域的请求后，会确认认证信息的正确性。认证通过后，返回包含Request-URI资源的响应。而此时，头域Authentication-Info中会写入一些认证成功的相关信息。DIGEST身份验证提供比BASIC身份验证更高级别的安全性，但与HTTPS客户端身份验证相比仍然较弱。DIGEST认证提供了防止密码窃听的保护机制，但没有防止用户伪装的保护机制。DIGEST认证与BASIC认证一样，使用起来没有那么方便灵活，仍然不能满足大多数网站对高安全级别的追求标准。因此，其适用范围也受到限制。4.SSL客户端认证对于使用用户ID和密码的认证方式，只要两者内容正确，就可以通过用户认证。但是，如果用户ID和密码被盗，则很有可能被第三方冒充。使用SSL客户端身份验证可以防止这种情况发生。SSL客户端认证是一种使用HTTPS客户端证书完成认证的方式。使用客户端证书（在HTTPS章节中解释）身份验证，服务器可以确认访问来自已登录的客户端。SSL客户端认证的认证步骤为了达到SSL客户端认证的目的，需要提前给客户端分发客户端证书，客户端必须安装这个证书。第一步：服务端收到资源认证请求后，会发送CertificateRequest消息，请求客户端提供客户端证书。第二步：用户选择好要发送的客户端证书后，客户端会将客户端证书信息以ClientCertificate报文的形式发送给服务器端。图：选择客户端证书示例（三菱东京UFJ银行）第三步：服务器验证客户端证书后，可以接收证书中客户端的公钥，然后开始HTTPS加密通信。SSL客户端认证采用双因素认证。在大多数情况下，SSL客户端认证并不仅仅依靠证书来完成认证。它一般与form-b??asedauthentication（后面会解释）结合起来形成双因素认证（Two-factorauthentication）。使用。所谓双因素认证，是指在认证过程中不仅需要密码作为一个因素，还需要申请人提供申请人持有的其他信息作为另一个因素，结合使用的一种认证方式它。也就是说，第一认证因素的SSL客户端证书用于认证客户端计算机，第二认证因素的密码用于确认是用户本人。通过双因素认证后，可以确认用户本人是使用正确的电脑访问服务器的。SSL客户端身份验证所需的费用使用SSL客户端身份验证需要使用客户端证书。但是客户端证书需要支付一定的费用才能使用。这里所说的费用是指从证书颁发机构购买客户端证书的费用，以及服务器运营商为保证自己搭建的证书颁发机构安全运行而产生的费用。每个认证机构颁发客户证书的成本是不同的，平均分配到一张证书上每年的成本大约是几万到几十万日元。服务器运营商也可以成立自己的认证机构，但会产生相应的费用以维护安全运行。五。基于表单的身份验证基于表单的身份验证方法未在HTTP协议中定义。客户端将登录信息（Credential）发送给服务器端的Web应用，根据登录信息的验证结果进行认证。根据实际安装的Web应用程序，提供的用户界面和身份验证方法也不同。图：基于表单的身份验证示例（Google）在大多数情况下，输入预先登录的用户ID（通常是任何字符串或电子邮件地址）和密码等登录信息后，将其发送到Web应用程序，并根据认证结果确定认证。成功。身份验证主要是基于表单的身份验证。由于使用方便和安全问题，HTTP协议标准提供的BASIC认证和DIGEST认证很少被使用。此外，虽然SSL客户端认证具有较高的安全性，但由于引入和维护成本等问题尚未普及。例如SSH和FTP协议，服务端和客户端之间的认证是符合标准规范的，满足安全使用级别最基本的功能需求，所以可以直接使用这些协议的认证。然而，对于Web站点的身份验证功能，目前还没有能够满足其安全使用级别的标准规范，因此不得不采用Web应用程序实现的基于表单的身份验证方法。没有通用标准规范的表单身份验证将在每个网站上以不同方式实现。如果是充分考虑安全性能实现的表单认证，则可以具有较高的安全级别。但是，在实施表单身份验证时遇到问题的网站并不少见。Session管理和cookie应用基于表单认证的标准规范还没有最终确定，cookie一般用于管理会话（session）。基于表单的身份验证本身是通过将客户端发送的用户ID和密码与先前通过服务器端Web应用程序登录的信息进行匹配来进行身份验证的。但是，由于HTTP是一种无状态协议，因此无法在协议级别保存先前经过身份验证的用户的状态。即无法实现状态管理，即使该用户下次继续访问时，也无法将他与其他用户区分开来。所以我们会用Cookie来管理Session来弥补HTTP协议中不存在的状态管理功能。第一步：客户端将用户名、密码等登录信息放入报文的实体部分，通常通过POST方式向服务器发送请求。在这种情况下，HTTPS通信用于显示HTML表单屏幕并发送用户输入数据。第二步：服务器会发出一个SessionID来识别用户。认证是通过验证客户端发送的登录信息来进行的，然后将用户的认证状态与SessionID绑定并记录在服务器上。当向客户端返回响应时，SessionID（例如PHPSESSID=028a8c...）将被写入头字段Set-Cookie。您可以将SessionID视为一种用于区分不同用户的等价数字。但是如果SessionID被第三方盗用，对方就可以冒充你的身份进行恶意操作。因此，必须防止SessionID被盗用或被猜测。为了实现这一点，SessionID应该使用不可预测的字符串，服务器端也需要管理有效期以确保其安全性。另外，为了减少跨站脚本（XSS）带来的危害，建议提前给cookie加上httponly属性。第三步：客户端收到服务器发送的SessionID后，会在本地保存为cookie。下次向服务器发送请求时，浏览器会自动发送cookie，因此SessionID也会发送给服务器。服务器可以通过验证接收到的会话ID来识别用户及其身份验证状态。除了上面描述的应用示例之外，还有其他应用不同方法的情况。另外，不仅登录信息和基于表单认证的认证过程没有标准化的方法，而且服务器应该如何保存用户提交的密码等登录信息也没有标准化。通常，一种安全的存储方式是先通过加盐（salt）1为密码增加额外信息，然后使用散列（hash）函数计算散列值并保存。但是我们也经常看到直接保存明文密码的做法，这种做法存在造成密码泄露的风险。（salt其实是服务器随机生成的一个字符串，但是长度一定要足够长，而且是真正随机生成的。然后把它和密码字符串（前后都有）连接起来，生成一个hash值。当两个用户的时候使用相同的密码，由于随机生成的salt值不同，对应的hash值也会不同，这样一来，密码的特征就大大降低了，攻击者就很难利用手中密码的特征库被破解。)以下是以往学习的总结，有需要的朋友可以去看看~~TCP/IP基础总结学习（一）-个人文章-SegmentFault思不https://segmentfault.com/a/11...TCP/IP基础总结学习（二）-个人文章-SegmentFault思无https://segmentfault.com/a/11...TCP/IP基础总结学习（三）-个人文章-SegmentFault思无https://segmentfault.com/a/11.../segmentfault.com/a/11...TCP/IP基础总结学习（四）-个人文章-SegmentFault思不https://segmentfault.com/a/11...TCP/IP基础总结学习（五）-个人文章-SegmentFault思考https://segmentfault.com/a/11...TCP/IP基础总结学习（六）-个人文章-SegmentFault思考https://segmentfault.com/a/11...TCP/IP基础总结学习（七）-个人文章-SegmentFault思考https://segmentfault.com/a/11...前端面试练习题总结：-个人文章-SegmentFault思考https://segmentfault.com/一个/11...
