[转载]Token原理以及应用

  近期因为项目须要开发供第三方使用的api，在整个架构设计的一个环节中，对api访问须要进行认证，在这里我选择了token认证。

一：token的优点（此部分引自http://www.sumahe.cn/）

    1.无状态、可扩展

        在客户端存储的Tokens是无状态的，而且可以被扩展。基于这种无状态和不存储Session信息，负载负载均衡器可以将用户信息从一个服  务   传到其余服务器上。

    若是咱们将已验证的用户的信息保存在Session中，则每次请求都须要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会形成  一些拥堵。可是不要着急。使用tokens以后这些问题都迎刃而解，由于tokens本身hold住了用户的验证信息。
 

    2.安全性

    请求中发送token而再也不是发送cookie可以防止CSRF(跨站请求伪造)。即便在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让咱们少了对session操做。

    token是有时效的，一段时间以后用户须要从新验证。咱们也不必定须要等到token自动失效，token有撤回的操做，经过token revocataion可使一个特定的token或是一组有相同认证的token无效。

           3.可扩展性

Tokens可以建立与其它程序共享权限的程序。例如，能将一个随便的社交账号和本身的大号(Fackbook或是Twitter)联系起来。当经过服务登陆Twitter(咱们将这个过程Buffer)时，咱们能够将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，能够提供可选的权限给第三方应用程序。当用户想让另外一个应用程序访问它们的数据，咱们能够经过创建本身的API，得出特殊权限的tokens。

4.多平台跨域

咱们提早先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，须要介入各类各类的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个经过了验证的token，数据和资源就可以在任何域上被请求到。

Access-Control-Allow-Origin: *

5.基于标准

建立token的时候，你能够设定一些选项。咱们在后续的文章中会进行更加详尽的描述，可是标准的用法会在JSON Web Tokens体现。

最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在将来的使用中你能够真正的转换你的认证机制。

 

二.Token的原理

 

 

1.将荷载payload，以及Header信息进行Base64加密，造成密文payload密文，header密文。

2.将造成的密文用句号连接起来，用服务端秘钥进行HS256加密，生成签名.

3.将前面的两个密文后面用句号连接签名造成最终的token返回给服务端

注：

（1）用户请求时携带此token（分为三部分，header密文，payload密文，签名）到服务端，服务端解析第一部分（header密文），用Base64解密，能够知道用了什么算法进行签名，此处解析发现是HS256。

（2）服务端使用原来的秘钥与密文(header密文+"."+payload密文)一样进行HS256运算，而后用生成的签名与token携带的签名进行对比，若一致说明token合法，不一致说明原文被修改。

 （3）判断是否过时，客户端经过用Base64解密第二部分（payload密文），能够知道荷载中受权时间，以及有效期。经过这个与当前时间对比发现token是否过时。

三，实现思路

 

1.用户登陆校验，校验成功后就返回Token给客户端。

2.客户端收到数据后保存在客户端

3.客户端每次访问API是携带Token到服务器端。

4.服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

注：若是其中有错误请你们指出，但愿你们共同进步