前端网络高级篇（二）身份认证

网络身份的验证的场景非常普遍，比如用户登陆后才有权限访问某些页面或接口。而HTTP通信是无状态的，无法记录用户的登陆状态，那么，如何做身份验证呢？

下面，会从浅入深，陆续介绍几种常用的认证方式和相关概念。文章较长，请耐心阅读。

1. 鉴权与授权

• 鉴权 Authentication，指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。 例子：用户名张三，密码******，用户名和密码通过挖财验证，登陆成功
• 授权 Authorization，一般是指获取用户的委派权限。 例子：我是张三，有权访问git/client/jizhang，因为gitlab给我进行了授权

image

一般流程为先鉴权再授权。而身份验证指的就是鉴权这个步骤。

1.2 常用的鉴权方式

• 方式一：HTTP Basic Authentication （401） 客户端发送http request 给服务器,服务器验证该用户是否已经登录验证过了，如果没有的话，服务器会返回一个401 Unauthozied给客户端，并且在Response 的 header “WWW-Authenticate” 中添加信息。 然后，浏览器弹出输入框要求输入用户名和密码。

image 用户输入正确的用户名和密码后，浏览器用BASE64编码，放在Authorization header中发送给服务器。如下图:

• 方式二：Session-cookie
• 方式三：Token
• 方式四：OAuth（开发授权）

后三种验证方式下面逐渐展开讲解。

2. Token VS Cookies

2.1 Cookies

Cookies是传统的鉴权方式，通过浏览器携带的Cookies字段来进行状态存储。特点如下：

• 认证信息在服务端需要存储。cookies携带sessionId，用户经过认证之后，应用都要在服务端做一次记录，以方便用户下次请求的鉴别。session的保存方法多种多样，可以保存在文件中，也可以内存里，或第三方媒介，比如redis或者mongodb。随着认证用户的增多，服务端的开销会明显增大。缺点
• 一般不需要客户端存储。服务端通过reponse: Set-Cookie头信息为客户端设置cookie，客户端不需要做特殊配置，浏览器会在后续的ajax请求中自动带上cookie。

• 有CSRF(跨站点伪造请求)风险。缺点
• 移动端用在使用cookie时有各种不便利和局限。缺点
• Cookie可以在同一域名下或者同一主域不同子域下共享，一旦跨主域，就无法共享缺点
• 分布式应用上，可能会限制负载均衡器的能力。用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。缺点

2.2 Token

Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

最简单的token组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。

相比Cookies，Token的优势明显多了。

• 服务端无需存储认证信息。因为Token本身就存储了认证信息。
• 需要前端存储（建议用localstorage）。客户端通过request: Authorization头信息设置Token，发给服务端做验证。缺点

• 无CSRF风险
• 适合移动端身份认证
• token支持各类跨域

Javascript支持Token如下：

// JS
var res = new XMLHttpRequest();
...
req.setRequestHeader('Authorization',accesstoken);
  
// JQuery
$.ajax({
   url: api,
   type: "GET",
   headers: { "Authorization": "Bearer " + token}
})

2.3 什么是JWT（Json web token)

JWT是实现Web应用会话管理的一种方式。广义上来讲，它是一种开发标准，而非技术实现（大部分的语言平台都有按照它规定的内容提供了自己的技术实现）；狭义上讲，它就是用来传递的Token字符串。

看一下JWT是如何传递的。

它长得像下面这样。。。

JWT是如何对信息签名加密的呢？ 要前面的信息分为三部分：header，payload和signature。

• header：说明这个JWT签发的时候所使用的签名和摘要算法

{
  "typ": "JWT",
  "alg": "HS256"
}

• payload：用来承载要传递的数据

{
  "sub": "1234567890",
  "name": "john Doe",
  "admin": true
}

• signature：密钥

签名过程：把header和payload对应的json结构进行base64url编码之后得到的两个串用英文句点号拼接起来，然后根据header里面alg指定的签名算法生成出来的。函数如下：

HMACSH256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

HMAC计算：https://1024tools.com/hmac

下面的内容都是基于Token认证

3. Token有效期

显而易见，身份验证必须要有有效期！那么，如何在”用户无感知”的情况下处理Token失效？

• 方案一： 服务器端保存 Token 状态，用户每次操作都会自动刷新（推迟） Token 的过期时间。
  • 缺点：请求次数多时，每次都刷新过期时间代价较大
• 方案二：refresh token
  • 优点：服务端不需要刷新token，避免频繁读写操作

那让我们看看什么是refresh token？

3.1 Refresh token

第一步，登陆。

第二步，业务请求

第三步，Token过期，刷新Token

那么，如果refresh token也过期呢？好吧，请重新登陆吧。

3.2 Refresh token自动续期

可以在Refresh token每次使用时，更新它的过期时间。也可以在创建Refresh token时，就指定它的过期时间，比如，距离创建时间XXX天后过期。

看到这里，大家应该觉得身份验证可以完美收官了。。。但是，前面所讲的技术都有一个大前提，就是，认证服务和业务服务在一起的。 比如，上淘宝网，用淘宝账号登陆，没有问题。 但是，现在很多网站都没有自己的账号密码，而是通过第三方账号登陆，比如微信，微博，QQ。

这种认证服务和业务服务分离的情况下，如何做身份认证呢？继续下面两节吧！

4. 分离认证服务

认证服务和业务服务分离时，利用Token的无状态特性，实现单点登陆。

第一步，登录和业务请求

第二步，更新Token

这样好像完美多了。但是，又有个问题，上图是在认证服务器信任业务服务器的场景下工作的。

问题1：如何处理不受信任的业务服务器呢？ 答案：使用非对称加密签名，认证服务器使用密钥A签发（私钥），业务服务器使用密钥B验证（公钥）。

问题2： 多个业务服务器之间使用相同的Token对用户来说是不安全的！！！任何一个服务器拿到Token都可以仿冒用户去另一个服务器处理业务，怎么处理？ 答案：认证服务器产生Token时，需要把使用方-业务服务器相关信息记录在Token中。

问题3：如果用户不信任业务服务器呢？ 答案：让『认证服务』帮助用户甄别『业务服务』！

开发式API可以解决上面的所有问题。

5. 开放式API - OAuth

OAuth 2.0是一个关于授权（authorization）的开放网络标准。

认证服务器不公开公钥， 业务服务需要在认证服务注册，通过审核，拿到特定公钥。 然后，用户通过认证服务器授权，将授权数据加密到Token中。

OAuth有四个角色：

• 资源拥有者(Resource Owner) - 用户
• 客户端(Client) - 三方应用
• 资源服务器(Resource Server) - 存放用户资源和信息
• 授权服务器(Authorization Server) - 给三方颁发授权令牌（access token）

授权流程如下图：