HTTP认证方式

最新推荐文章于 2022-06-02 15:33:55 发布

鹤啸九天-西木

最新推荐文章于 2022-06-02 15:33:55 发布

阅读量1.5k

点赞数

分类专栏：标准规范通讯网络安全文章标签： Auth Authorization 认证安全 HTTP

本文链接：https://blog.csdn.net/lzghxjt/article/details/104806995

版权

标准规范同时被 3 个专栏收录

47 篇文章 0 订阅

订阅专栏

通讯网络

19 篇文章 0 订阅

订阅专栏

安全

9 篇文章 1 订阅

订阅专栏

一、基本认证（Basic Auth）

是一种比较简单的HTTP认证方式，当客户端访问使用此认证方式的服务端时，响应头中WWW-authenticate为Basic，需要客户端传入用户名username和密码password，如果认证成功，响应头Authorization-Info会返回认证相关的信息。浏览器关闭时清除用户名和密码。请求方式有两种：

1、把用户名和密码用:（半角冒号）连接，拼成username:password，再与ip:port之间用@连接，拼在URL中直接请求，形如username:password@ip:port；

2、把用户名和密码用:（半角冒号）连接，拼成username:password，之后对username:password进行Base64编码。在字符串“Basic”之后追加一个空格，然后再追加该Base64编码，生成一个新的字符串。将此字符串作为Header请求头中Authorization的值，形如：Authorization:Basic XXXXXX，直接请求即可；

二、摘要认证（Digest Auth）

为了弥补基本认证的不安全性，通过“密码摘要”进行认证，可以大大提高安全性。当客户端访问使用此认证方式的服务端时，响应头中WWW-authenticate为Digest。如果认证成功，响应头Authorization-Info会返回认证相关的信息。在通信的过程中，有一些参数需要说明：

参数	说明
realm	服务端返回的响应头WWW-authenticate中的内容，指明受保护的域，也就是要输入的用户名和密码是哪个域的
qop	服务端返回的响应头WWW-authenticate中的内容，指明质量保护策略，可选auth或auth-int，auth-int增加了报文完整性检测
nonce	服务端返回的响应头WWW-authenticate中的内容，是一个随机数，这个数会经常变化。客户端计算密码摘要时将其附加上去，使得多次生成同一用户的密码摘要各不相同，用来防止重复攻击
nc	客户端请求头Authorization中的内容，是一个用16进制表示的nonce计数器。表示同一nonce下客户端发出请求的数量
cnonce	客户端请求头Authorization中的内容，是一个不透明的字符串随机数，客户端和服务器都会使用
nextnonce	服务端返回的响应头Authorization-Info中的内容，表示下一个服务端的nonce，使客户端可以预先发送正确的摘要
rspauth	服务端返回的响应头Authorization-Info中的内容，响应的摘要，用于客户端对服务端进行认证
stale	服务端返回的响应头WWW-authenticate中的内容，当nonce过期时，服务器返回一个附带新nonce的401响应，并指定stale=true，表示服务器告知客户端用新nonce来重试，而不是要求用户重新输入用户名和密码了

生成摘要digest的算法分两种：

1、RFC 2069 的认证规范中定义生成摘要的方式是：

HA1 = MD5(username:realm:password)
HA2 = MD5(method:URI)
digest = MD5(HA1:nonce:HA2)

2、RFC 2617 的认证规范中定义生成摘要的方式是：

1>生成HA1的方式：

①算法指令未指定，或者是MD5：

HA1 = MD5(username:realm:password)

②算法指令是MD5-sess：

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

2>生成HA2的方式：

①质量保护指令未指定，或者是auth：

HA2 = MD5(method:URI)

②质量保护指令是auth-int：

HA2 = MD5(method:URI:MD5(entityBody))

3>最终生成摘要digest的方式：

①质量保护指令未指定：

digest = MD5(HA1:nonce:HA2)

②质量保护指令是auth或者auth-int：

digest = MD5(HA1:nonce:nc:cnonce:qop:HA2)

三、OAuth认证（Open Auth）

是一个开放的授权协议，用来分离两种不同的角色：第三方和资源所有者。经过资源所有者同意后，第三方可以得到令牌，通过令牌，第三方再去请求数据。与以往授权机制不同的是OAuth可以让第三方接入方不需要使用用户的帐号信息（如用户名与密码）就可以申请获得该用户资源的授权。常见场景如：某应用要使用QQ或微信账号及头像等。 OAuth涉及到的角色有：（第三方）接入方，服务（提供）方以及用户，OAuth有两个版本，其中：

1、OAuth1.0的流程是：

①接入方使用服务方分配的接入方唯一标识consumer_key，获取到未授权的token和token_secret；

②接入方使用未授权的token以及callback_url重定向请求服务方，使token得到授权。此时需要用户的确认授权操作，需要用户在服务方输入用户名和密码以验证身份，并且指定可访问的资源范围。 token授权成功后回调callback_url返回接入方；

③接入方使用consumer_key、已经授权的token请求服务方，换取access_token和access_token_secret；

经过前3步之后，接入方就可以使用consumer_key、access_token来访问服务方中已授权的资源信息。但是在OAuth1.0中步骤②中，可能会存在两种漏洞：

❶如果重定向请求token授权的URL被抓取到，并且发给了想要盗取的用户，当用户误点完成授权后，最终得到的access_token将是该用户的资源信息；

❷如果token授权完成后服务方回调的callback_url被篡改，回调的是攻击者值入的URL；

针对此漏洞，OAuth协议发布了修正的版本，包括很多小的错误更正，就是OAuth 1.0 Core Revision A，一般称为OAuth 1.0a。第一个主要修改是在步骤②去除了callback_url入参，而是将callback_url加到步骤①入参中，这样攻击者一来没法预测callback_url的值，二来没法篡改callback_url，因为需要签名；第二个主要修改是在步骤②返回的时候，增加了一个oauth_verifier参数，并且在换取access_token的时候进行验证，确保授权的用户和换取access_token的用户是同一个人。

2、OAuth2.0有四种获取令牌的方式，分别是：

①授权码方式：是指第三方先申请一个授权码，通过callback_url的URL参数返回。然后再用该码获取令牌。这种方式最常用，安全性也最高，适用于那些有后端的 Web 应用。授权码通过前端传入，令牌则储存在后端，而且所有与服务方的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

②授权码隐藏方式：有些 Web 应用是纯前端应用，没有后端，这时就不能用授权码方式，而是直接请求获取到令牌，将令牌放在callback_url的URL锚点中返回。这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

③密码方式：对第三方高度信任，可以直接使用用户的用户名和密码，通过响应体中直接获取令牌。由于需要用户自己的用户名和密码，风险很大，因此只适用于其他授权方式都无法采用的、而且必须是用户高度信任的应用。

④凭证方式：适用于没有前端的命令行应用，即在命令行下请求获取令牌。这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共用同一个令牌。

令牌获取以后，在请求的头信息中，加上Authorization字段，令牌就放在这个字段里面，形如Authorization:Bearer XXXXXX。令牌有效期到了之后，如果让用户重新走一遍上面的流程申请新令牌，体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌，具体方法是：服务方一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌。令牌到期前，用户使用refresh_token发一个请求更新令牌。

参考：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.htm