导读：很多时候用户提交username + pwd 服务端验证通过后，返回一个令牌token。这里需要注意的几个部分是要为未来的升级做好准备。我经常遇到...
很多时候用户提交username + pwd 服务端验证通过后，返回一个令牌token。
这里需要注意的几个部分是要为未来的升级做好准备。我经常遇到的几个初期设计是：
1.验证通过后，把用户uid+username+salt等md5后，作为token返回到客户端。
2.对token加入时间戳，过期后客户端重新提交username + pwd验证后再发一个token到客户端
3.服务端生成一个token后下发到客户端，客户端按照约定的规则加密后请求服务端。
先说第一种带来的问题：生成的token永久不变，那么别人获取到一个token就可以无限制的进行请求。直到你关闭了这个接口为止。为后续安全设计增加了成本。
第二种问题就有点老火了，虽然看似token只在一定时间范围内有效了，但是其实更不安全了。首先客户端需要保存用户的用户名与密码，如果用户手机平时不注重安全，很容易被人窃取。
第三种设计方案，这是我原先干过的一件事，是这三种方案中最垃圾的设计。得出的教训就是：绝不能把任何加密的事情交给客户端。这样子灵活性大打折扣。举例：还是升级接口了，现在本来token生成只是服务端的事情，服务端随时可动态改变规则，现在由于客户端也参与进来了，这事儿就麻烦了，你一改，客户端也要跟着改。没有任何灵活性可言。切记：客户端就接收，然后转发回服务端就好了。别再客户端进行加密！！！
经过这些坑的历练，参考oauth2.0，我现在采用以下方案：
用户提交username + pwd后，服务端返回以下信息：
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
access_token 是用来进行访问的接口的，expires_in 是他的过期时间，到达过期时间后，需要用 refresh_token 来请求服务端刷新 access_token。
这里几个重点是：refresh_token 仅能使用一次，使用一次后，将被废弃。另外这个 access_token 只在 expires_in 有效期内有效。
注意： 这里的 expires_in 仅返回秒数就好了。别返回时间戳。因为各个平台计算s的时间戳，不一致，这样子做更方便处理。
