【读】这一次,让我们再深入一点 - HTTP的基本认证机制

这是网络系列的第九篇文章,接下来会有更多精彩内容.敬请期待! 让我们一起乘风破浪!

前言

哈哈, 好久没和大家一起学习了. 春节有没有很嗨皮啊? 反正我是懒着过去的....今天再和大家一起进步一点点.

网络的资源如此之多, 但有些资源为了安全, 不是所有人都可以看到的. 此时, 服务器需要客户端证明自己 的身份, 该篇一起来了解下HTTP的基本认证机制.

HTTP的质询/响应认证框架

HTTP提供了一套原生的质询/响应(challenge/response)框架. 其认证模型如下:

• 在客户端发起HTTP请求时, 服务器并没有直接完成客户端的需求, 而是以"认证质询"的方式响应, 要求客户端提供身份信息.
• 客户端再次请求时, 就要附带证明其身份的信息(用户名密码或证书等), 向服务器说明自己的真实性.

需要了解的几个问题

认证协议与首部

HTTP的质询/响应框架支持两种官方的认证协议: 基本认证和摘要认证(摘要认证会在后续文章中一起学习). 两种协议对应的HTTP首部及内容也有所区别.先来看看基本认证协议使用的首部信息.

认证步骤	首部	描述	方法/状态
请求		在不知道需要认证时没有具体首部	GET
质询	WWW-Authenticate	服务器返回状态码401,拒绝请求; 要求客户端提供用户名和密码. 服务器可能分为不同的区域,每个区域都需要不同的认证, 这些信息都会在WWW-Authenticate响应头中描述; 该首部也会包含对应的认证算法.	401 Unauthorized
授权	Authorization	客户端再次发出请求, 附加Authorization首部, 说明用户名和密码已经认证算法.	GET
成功	Authentication-Info	若认证通过, 服务器返回对应资源. 可以在该响应头中返回附件信息.	200 OK

参考下面的实例:

安全域

在上述实例中, 质询的响应包含了WWW-Authenticate: Basic realm="Family"的信息; 服务器可能会把多个文档划分在不同的域中, realm是服务器对各个域的标识. 不同的域可能需要不同的认证.

Base-64编码

在上述实例的C请求中, 用户名和密码经过Base-64编码之后通过Authorization首部传到服务器. 这里并不是明文传输.更多关于Base-64的说明看这里.当然,这一步的转换并不能保证用户名和密码的安全.

代理认证

代理作为web结构中的实体, 也可以为用户提供认证的功能.示意图如下:

使用代理进行认证, 是一种快捷管理的方式. 可以看到, 认证过程和web服务器的认证过程相同.但相关头信息和状态码不同:

web服务器首部	代理认证首部
Unauthorized status code 401	Unauthorized status code 407
WWW-Authenticate	Proxy-Authenticate
Authorization	Proxy-Authorization
Authentication-Info	Proxy-Authentication-Info

基本认证存在的问题

在了解了基本认证的过程后, 可以了解到它存在的一些问题:

• 用户名和密码通过网络经Base-64编码后传输, 会导致第三方截获并解码后获取用户的隐私信息.

• 即使第三方无法直接获取用户名密码, 也可以通过 将截获的数据重放给服务器以获取服务器的访问权限.

• 用户面对大量的用户名和密码时, 有可能使用相同的密码, 这将带来"撞库"的危险.

• 总之, 基本认证存在很大的风险.

结语

该篇和大家一起了解了HTTP的基本认证框架. 除了基本的认证, HTTP还支持摘要认证, 下篇我们继续学习.到时候见!

注

• 部分图片来源于网络，如有侵权，请告知。
• 如有错误，还请指出。共勉！
• 您的喜欢是最大的赞赏。