近期，因公司需要，在调研API网关的相关资料。API网关包括了很多功能，其中有一项就是权限认证，这里为方便日后追踪资料，所以就总结一下自己觉得合适的一套权限验证吧。
首先，我们要先了解权限认证的功能：
权限认证，其实就是对客户端（如App）的请求校验，在这个权限认证里面，你可以做一些安全性的功能，比如黑名单等。
在我们清楚了权限认证的定位之后，我们就可以展开我个人认为可以采取的权限认证方案了。我个人采取的方案是OAuth2.0+JWT。
首选，我们介绍下OAuth2.0：
详细的可以参考阮一峰的Blog我这里就简单介绍下：
我们看看OAuth2.0的运行流程
（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
（F）浏览器执行上一步获得的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。
以上是他的通用流程。不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。
客户端授权模式有很多种，我就不列举了，有兴趣可以去阮一峰的Blog看看，这里，我只介绍我们需要用到的客户端模式。
客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
它的步骤如下：
（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
（B）认证服务器确认无误后，向客户端提供访问令牌。
A步骤中，客户端发出的HTTP请求，包含以下参数：
granttype：表示授权类型，此处的值固定为"clientcredentials"，必选项。
scope：表示权限范围，可选项。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
认证服务器必须以某种方式，验证客户端身份。
B步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
这个就是我们将要使用到的OAuth2.0的流程。
上面有提到，OAuth2.0在请求网关的时候，是需要一个tooken的，那么，如果处理这个tooken呢？这里引用一个叫JWT的概念。
首选，这里要提及一点，我们的tooken，是存放在我们的request header里面的。也就是说，当我们的请求被拦截的时候，我们的tooken，其实很容易就被获取到，那么，我们的tooken的安全性就要注意了，如何才能保证我们的tooken安全？JWT能够帮我们处理。
关于JWT详细的内容，我们可以参考这里
这里说明一下，JWT只是一种标准，它有自己的通用语法，而且，他能附带很多信息，基于这些信息，我们可以作很多传输扩展，但是JWT他本身是并不能解决安全问题的，他需要解决RSA签证（记得，证书一定要放在服务端），这样，我们的tooken，就很难被伪造了。
这就是整个验证的通讯过程。
总结优缺点：
优点：
1、不同的用户他的鉴权信息是不一样的。
2、密钥是保存在服务端的，即使破解客户端，也无法拿到验签。
3、即使他使用源码，使用自己的账号，拿到自己的鉴权信息，也只能对自己的账号进行操作，但是同样的，我们发现用户账号有异常的情况下，我们可以作黑名单处理。
缺点：
用户的账号密码，一定不能泄漏，否则，完全可以模拟，不过，似乎如果这些信息以后，任何算法也是悲催的。
后续有新的详细，继续更新....
