接口测试鉴权初了解

Posted 2021-06-23 黑黑白白君

文章目录

• • 1.1 什么是鉴权？
  • 1.2 常见的鉴权方式
  • • 1、HTTP Basic Authentication鉴权方式
    • • HTTP Basic Authentication鉴权方式的认证过程：
      • HTTP Basic Authentication鉴权方式的注销
      • HTTP Basic Authentication鉴权方式的适用范围
    • 2、token鉴权方式
    • • token鉴权方式流程：
      • token鉴权方式适用场景
      • • *JWT（JSON WEB TOKEN）
    • 3、session + cookie鉴权方式
    • • session+cookie认证流程：
      • *session+cookie和token的区别
      • • 是否含有用户的登录状态：
        • 是否需要cookie（适用客户端的类型有所区别）：
        • 时效性：
        • 可扩展性：
    • 4、OAuth（开放授权）鉴权方式
    • • auth2.0的流程：

---

1.1 什么是鉴权？

鉴权是指验证用户是否有权利访问系统的行为。

1.2 常见的鉴权方式

1、HTTP Basic Authentication鉴权方式

这是HTTP协议实现的基本认证方式，我们在浏览网页时，从浏览器正上方弹出的对话框要求我们输入账号密码，正是使用了这种认证方式。

• HTTP Basic Authentication鉴权方式的认证过程：

  1. 客户端向服务器请求数据，请求的内容可能是一个网页或者是一个ajax异步请求。此时，假设客户端尚未被验证，则客户端提供如下请求至服务器：
     Get /index.html HTTP/1.0
     Host:www.google.com
  2. 服务器向客户端发送验证请求代码401，（WWW-Authenticate: Basic realm=“google.com”，这句话是关键，如果没有，客户端不会弹出用户名和密码输入界面）。
  3. 当符合http1.0或1.1规范的客户端（如IE，FIREFOX）收到401返回值时，将自动弹出一个登录窗口，要求用户输入用户名和密码。
  4. 用户输入用户名和密码后，将用户名及密码以BASE64加密方式加密，并将密文放入前一条请求信息中。
  5. 服务器收到上述请求信息后，将Authorization字段后的用户信息取出、解密，将解密后的用户名及密码与用户数据库进行比较验证，如用户名及密码正确，服务器则根据请求，将所请求资源发送给客户端。

• HTTP Basic Authentication鉴权方式的注销

  认证成功后，客户端每次发送请求都会带上Authorization头部参数，除了使session过期外，客户端如何主动注销登录呢？目前最有效的方式：

  • 服务端专门设置一个专门用于注销的账号。
  • 客户端在注销操作的时候主动去修改请求头Authorization信息，当服务端读取到是这个专用于注销的账户，就执行注销流程。

• HTTP Basic Authentication鉴权方式的适用范围

  • 这种认证方式存在缺陷，首先它把加密后的账密直接放在请求头，加上base64加密的方式是可逆的，这样账密就容易泄露。
  • 所以这种认证方式一般用于对安全要求性不高的系统上。

---

2、token鉴权方式

• token鉴权方式流程：

  1. 客户端使用账密请求登录
  2. 服务端收到请求，验证账密
  3. 账密验证通过，服务端生成一个token，再把token发送给客户端
  4. 客户端将token存储起来，可以放在cookie或者其他方式如Local Storage 里
  5. 以后客户端每次发送请求都需要带上token
  6. 服务端收到请求后验证token的合法性，校验通过则返回资源，不通过则返回401状态码（鉴权失败）

• token鉴权方式适用场景

  • token验证比较灵活，适用于大部分场景。
  • 常用的token鉴权方式的解决方案是JWT（JSON WEB TOKEN），JWT是通过对带有相关用户信息的JSON进行加密来实现授权验证的方案，加密的方式比较灵活，可以根据需求具体设计。

*JWT（JSON WEB TOKEN）

JWT是Auth0提出的通过对JSON进行加密签名来实现授权验证的方案。

• 登陆成功后将相关信息组成json对象，然后对这个对象进行某中方式的加密，返回给客户端。
• 客户端在下次请求时带上这个token，服务端再收到请求时校验token合法性，其实也就是在校验请求的合法性。
  
  

JWT对象通常由三部分构成：

• Headers： 包括类别（typ）、加密算法（alg）
• Claims ：包括需要传递的用户信息
• Signature： 根据alg算法与私有秘钥进行加密得到的签名字串， 这一段是最重要的敏感信息，只能在服务端解密。

---

3、session + cookie鉴权方式

利用服务器端的session（会话）和浏览器端的cookie来实现前后端的认证。

• 由于http请求时是无状态的，服务器正常情况下是不知道当前请求之前有没有来过。
• 这个时候我们如果要记录状态，就需要在服务器端创建一个会话(seesion)，将同一个客户端的请求都维护在各自的会话中。
• 每当请求到达服务器端的时候，先去查一下该客户端有没有在服务器端创建seesion，如果有则已经认证成功了，否则就没有认证。

• session+cookie认证流程：

  1. 服务器在接受客户端首次访问时在服务器端创建session，然后保存session（我们可以将session保存在内存中，也可以保存在redis中，推荐使用后者），然后给这个session生成一个唯一的标识字符串，然后在响应头中附上这个唯一标识字符串。
  2. 签名。这一步只是对sid进行加密处理，服务端会根据这个secret密钥进行解密。（非必需步骤）
  3. 浏览器中收到请求响应的时候会解析响应头，然后将sid保存在本地cookie中，浏览器在下次http请求的请求头中会带上该域名下的cookie信息。
  4. 服务器在接受客户端请求时会去解析请求头cookie中的sid，然后根据这个sid去找服务器端保存的该客户端的session，然后判断该请求是否合法。

*session+cookie和token的区别

session-cookie是通过sessionid来作为浏览器和服务端的链接桥梁，而token验证方式貌似是token来起到sessionid的角色。其实这两者差别是很大的。

• 是否含有用户的登录状态：

  • sessionid 只是一个唯一标识的字符串，服务端是根据这个字符串来查询在服务器端保持的session，这里面才保存着用户的登陆状态。
  • 而token本身就是一种登陆成功凭证，他是在登陆成功后根据某种规则生成的一种信息凭证，里面本身就保存着用户的登陆状态。服务器端只需要根据定义的规则校验这个token是否合法就行。
    
    

• 是否需要cookie（适用客户端的类型有所区别）：

  • session-cookie是需要cookie配合的，那么在http代理客户端的选择上就是只有浏览器了，因为只有浏览器才会去解析请求响应头里面的cookie，然后每次请求再默认带上该域名下的cookie。
  • 但是token不一样，是在登陆成功后在请求响应体中返回的信息，客户端在收到响应的时候，可以把它存在本地的cookie/storage/内存中，然后在下一次请求的请求头中带上这个token就行了。所以适用浏览器（即使禁止了cookie），还有原生APP等等。
    
    

• 时效性：

  • session-cookie的sessionid是在登陆的时候生成的，而且直到登出时一直不变，在一定程度上安全就会低。
  • 而token是可以在一段时间内动态改变的。
    
    

• 可扩展性：

  • token验证本身是比较灵活的，一是token的解决方案有许多，常用的是JWT。二来我们可以基于token验证机制，专门做一个鉴权服务，用它向多个服务的请求进行统一鉴权。

---

4、OAuth（开放授权）鉴权方式

OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。

• 为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式地向用户征求授权。

我们常见的提供OAuth认证服务的厂商有支付宝、QQ、微信。

• 从用户角度来说，第三方授权可以让我们快速的登陆应用，无需进行繁琐的注册，同时不用记住各种账号密码。只需要记住自己常用的几个账号就ok了。
• 从产品经理的角度来所，这种授权方式提高用户的体验满意度，另一方面可以获取更多的用户。

OAuth协议又有1.0和2.0两个版本。相比较1.0版，2.0版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。

• auth2.0的流程：

  1. 向用户请求授权，现在很多的网站在登陆的时候都有第三方登陆的入口，当我们点击等第三方入口时，第三方授权服务会引导我们进入第三方登陆授权页面。
  2. 当用户点击授权并登陆后，授权服务器将生成一个用户凭证（code）。
  3. 第三方应用后台通过第二步的凭证（code）向授权服务器请求Access Token，即请求授权服务器授权。
  4. 授权服务器同意授权后，返回一个资源访问的凭证（Access Token）。
  5. 第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。
  6. 资源服务器验证凭证（Access Token）通过后，将第三方应用请求的资源返回。
     

---

【部分内容参考自】

• 常见的鉴权方式，你真的不想知道吗：https://www.jianshu.com/p/4a00c0c3bf1d
• 前后端常见的几种鉴权方式：https://blog.csdn.net/wang839305939/article/details/78713124/