Token签名的设计

Token
使用JWT Token
JWT设计的好处是不用在服务器保持授权信息，会话不需要服务器维护
缺陷： 1，Token一旦签发，在有效期内不受控制，即服务端修改Token有效期时，之前签发的Token在过期前还是有效的 2，Token在过期后需要重新签发
签名的设计
       原理：用户登录后向服务器提供用户认证信息（如账户和密码），服务器认证完后给客户端返回一个Token令牌，用户再次获取信息时，带上此令牌，如果令牌正取，则返回数据。对于获取Token信息后，访问用户相关接口，客户端请求的url需要带上如下参数：
      时间戳：timestamp
        Token令牌：token
       然后将所有用户请求的参数按照字母排序（包括timestamp，token），然后使用MD5加密（需要加盐），全部大写，生成sign签名，这就是所说的url签名算法。登录后每次调用用户信息时，带上sign，timestamp，token参数。
例如：原请求https://www.andy.cn/api/user/update/info.shtml?city=北京 （post和get都一样，对所有参数排序加密）
 加上时间戳和token https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc
      然后根据url参数生成sign
 最终的请求如https://www.andy.cn/api/user/update/info.shtml?city=北京&timestamp=12445323134&token=wefkfjdskfjewfjkjfdfnc&sign=FDK2434JKJFD334FDF2
其最终的原理是减小明文的暴露次数；保证数据安全的访问。
具体实现如下：
  1. 客户端向服务端请求一次用户认证信息（用户名和密码），服务端接收到该请求后，验证用户信息是否正确。
        如果正确：则返回一个唯一不重复的字符串（一般为UUID），然后在Redis（任意缓存服务器）中维护Token----Uid的用户信息关系，以便其他api对token的校验。
        如果错误：则返回错误码。          
  2.服务器设计一个url请求拦截规则
(1)判断是否包含timestamp，token，sign参数，如果不含有返回错误码。
(2)判断服务器接到请求的时间和参数中的时间戳是否相差很长一段时间（时间自定义如半个小时），如果超过则说明该url已经过期（如果url被盗，他改变了时间戳，但是会导致sign签名不相等）。
(3)判断token是否有效，根据请求过来的token，查询redis缓存中的uid，如果获取不到这说明该token已过期。
(4)根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）。
(5)此url拦截只需对获取身份认证的url放行（如登陆url），剩余所有的url都需拦截。
    3.Token和Uid关系维护
    对于用户登录我们需要创建token–uid的关系，用户退出时需要需删除token–uid的关系。