Vue应用框架整合与实战--前后端分离后的安全控制篇

JWT 机制

什么是JWT

JWT——Json web token 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准，可实现无状态、分布式的Web应用授权。

我们为什么需要JWT

首先，当前后端分离时我们会因为同源策略而无法设置cookie和sessionid。当然了我们有很多方式去解决这个问题，比如反向代理和jsonp等。但这仍然不如直接使用jwt来的简便。其次就是要说到jwt与传统的身份认证相比有什么优势了。

回答这个问题需要来看看基于token的认证和传统的session认证的区别

• 传统的session认证

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了,这就是传统的基于session认证。

但是这种基于session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来.

• 基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程上是这样的：

• 用户使用用户名密码来请求服务器
• 服务器进行验证用户的信息 服务器通过验证发送给用户一个token
• 客户端存储token，并在每次请求时附送上这个token值 服务端验证token值，并返回数据
• 这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，
  另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin:*。

也就是说相比于传统基于cookie的session，基于token的jwt有以下优点：

• Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
• 无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
• 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
• 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
• 更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
• CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
  性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
• 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
• 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.

JWT的原理及构成

JWT的构成：

jwt由三部分构成：头部（header)、载荷（payload, )、签证（signature).

• 头部：jwt的头部承载两部分信息：

声明类型，这里是jwt
声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON：

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

然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
playload

• 载荷：就是存放有效信息的地方。，这些有效信息包含三个部分

标准中注册的声明
公共的声明
私有的声明
标准中注册的声明 (建议但不强制使用) ：

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

公共的声明 ：
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

私有的声明 ：
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

定义一个payload:

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

然后将其进行base64加密，得到Jwt的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
signature

• 签证：这个签证信息由三部分header (base64后的)
  payload (base64后的)
  secret分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

// javascript
var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);

var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用.连接成一个完整的字符串,构成了最终的jwt.

防止api接口被恶意调用或攻击

• 图形验证码：
  将图形校验码和手机验证码进行绑定，在用户输入手机号码以后，需要输入图形校验码成功后才可以触发短信验证，这样能比较有效的防止恶意攻击。目前大部分应用都是采用这种方式。

• 限定请求次数：
  在服务器端限定同IP，同设备，同时间范围内的接口请求次数。比如同一号码重复发送的时间间隔,一般为60或120秒；设置每个IP每天最大的发送量；设置单个手机号每天的最大发送量。

• 流程条件限定：
  将手机短信验证放在最后进行，比如需要用户必须注册后，或者用不必须填写了某些条件才能进行短信验证。

• 归属地是否一致：
  服务器端检查用户的IP所在地与手机号归属地是否匹配，如果不匹配则提示用户手动操作等。

• 服务器接口验证：
  当用户登录成功后，返回一个由Token签名生成的秘钥信息(Token可使用base64编码和md5加密，可以放在请求的Header中)，然后对每次后续请求进行Token的封装生成，服务器端在验证是否一致来判断请求是否通过。

• 采用https：
  线上的api接口开启https访问,这样做的话别人抓包的难度会提高很多，而且https需要秘钥交换，可以在一定程度上鉴别是否伪造IP。

• 服务器端代理请求：
  针对于网站，这也是解决跨域的方案之一，采用服务器代理可以有效的防止接口真实地址的暴露。

• 其它：
  当接口存在大量肉鸡攻击的时候，攻击者也同样容易暴露意图，我们可以通过系统分析算法，让攻击者获取不到有效数据，提高攻击成本。