系统访问安全认证（接口访问权限）
一、概述
通常除了第三方接口或者规定的需要加入白名单的接口不进行认证外，其他http接口请求都需要进行权限认证，以保证接口的安全。
二、基于Session认证
Session验证原理：
Cookie-session 认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效；
但是这种基于cookie-session的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于session认证应用的问题就会暴露出来。
基于session认证所显露的问题：
服务端开销大
每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性受到限制
用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
CSRF攻击
因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击
三、基于Token+签名验证规则
背景介绍：
当我们处理接口请求时，想必都会考虑到接口安全性问题，那么在写开放的API接口时是如何保证数据的安全性的？先来看看有哪些安全性问题在开放的api接口中，我们通过http Post或者Get方式请求服务器的时候，会面临着许多的安全性问题，例如：
请求来源(身份)是否合法？
请求参数被篡改？
请求的唯一性(不可复制)，防止请求被恶意攻击
为了保证数据在通信时的安全性，我们可以采用TOKEN+参数签名的方式来进行相关验证。
不进行验证的情况
api查询接口：
客户端调用：http://api.XXX.com/getProduct?id=vaule
如上，这种方式简单粗暴，在浏览器直接输入"http://api.XXX.com/getProduct?id=vaule"，即可获取产品列表信息了，但是这样的方式会存在很严重的安全性问题，没有进行任何的验证，大家都可以通过这个方法获取到产品列表，导致产品信息泄露。
那么，如何验证调用者身份呢？如何防止参数被篡改呢？如何保证请求的唯一性？ 如何保证请求的唯一性，防止请求被恶意攻击呢？
使用Token+签名认证 的情况（保证请求安全性）
Token+签名认证的主要原理
1.做一个认证服务，提供一个认证的webapi，用户先访问它获取对应的token
2.用户拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api
3.服务器端每次接收到请求就获取对应用户的token和请求参数，服务器端再次计算签名和客户端签名做对比，如果验证通过则正常访问相应的api，验证失败则返回具体的失败信息
Token认证的优点：
支持跨域访问
Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
无状态(服务端可扩展行)
Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
更适用CDN:
可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
去耦:
不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
更适用于移动应用
当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
CSRF(跨站请求伪造Cross-site request forgery)
因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
性能:
一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
不需要为登录页面做特殊处理:
如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
基于标准化
你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）
附：
为什么要使用TOKEN+签名认证的方式？单独使用TOKEN或者单独使用签名认证不行吗？详见
