嗯，就是这么做吧。 就相当于 cookie 一样。

大概是这样做，token 就相当于会话的 id，不过你提到的 token 生成机制貌似有缺陷，通过加密方式生成的话难以让 token 失效（过期），不如维护一个 token（user_id, token, expired_at）表，在登录的时候为会员生成 token，把会员 id 和 token 关联起来，另外存一个过期时间，通过时间控制 token 有效性。

大体流程对的。 token 加解密没必要，也不能增加安全性。只要在数据库绑定 token 和设备以及网络的关系，设定过期时间，就安全了。

#2 楼 @vincent 没做过移动这块哈，token 通过 response header 发送出去，那是一个自定义的 header 吗？如果是自定义的话，request header 下次不会自动带过来吧 还是说 api 返回 json 中有 token，然后客户端存下来下次再掉 api 的时候一起发送过来 谢谢！

#4 楼 @jayliud 可以用 header 传 token，也可以用普通参数传 token，通常客户端登录成功后就一直保存这个 token（同时保存过期时间），每次请求的时候都带上 token。

#5 楼 @vincent 这种会话保存机制除了用在用户登录验证之外，在移动端还可以用来做点啥呢？

考虑过用长连接来做么

@vincent 基本都解释了，其实本质上和 web 上的 cookie 类似，就是换成 token 了。

1.最基础的版本可以看成是一个永不过期的 cookie，客户端存储存储，利用这个来实现验证，相当于保持登录状态，当然安全性比较差一点；

2.继续高级一点就是给 token 增加过期时间提高安全性；

3.再高级一点可以添加一个 refresh_token 用于刷新 access_token，就是用 refresh_token 换 access_token，可以参考微信的方法：https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&lang=zh_CNaccess_token（移动开发》微信登录），具体的一些细节可以根据实际情况来改进，首次登录的时候用用户名密码换取 和 refresh_token，以后不需要用户名密码，通过 refresh_token 去刷新 access_token 即可，重新登录同理，外加一个请求作用域 scope 基本是比较安全了，根据自身情况做调整；

4.“这种会话保存机制除了用在用户登录验证之外，在移动端还可以用来做点啥呢？”作为资源请求的凭证，比如查看文章，需要用户登录才能查看，游客状态无法查看，那么就需要带上 access_token，再请求资源的时候来判别当前用户是否有权访问资源；

5.header 头或者普通参数看你自己选择，header 头看起来高端一些，你可以自定义一个 header 头属性，客户端存储这个 token，每次需要验证权限的请求一起发送；

有些理解可能有偏差，仅供参考

感谢各位的细心解答

我只是来给 wikimo 点赞的