api 使用session替代token 的利弊在哪?

补充:几种常用的验证机制
最近写app的api,使用laravel 框架的session替代了传统的存贮到数据库的token作为校验登录用户的方法!
以下是我们目前的做法

  1. 登录后后台生产session,会往返回信息head头里写一个set_cookie

  2. ios和安卓 会从head头里得到拿到这个cookie的东西

  3. 然后再请求需要登录的地方的时候,ios和安卓会把cookie放到head头里,让框架完成自我的校验

ps:

  1. 有人说不安全

  2. 有人说不好管理

  3. 有人说性能问题

有谁具体研究过,请帮我分析分析其利弊

我个人认为的观点:

  1. 说session不安全的,感觉有点牵强,假如真的一点不安全的话,那网站也就完全被暴露了,而且laravel的session也是有自己加密的方式,不是直接暴露的!

  2. 有人说不好管理,放在redis里了,我不太知道不好管理在哪里。

  3. 性能问题,session可以存贮的位置有很多,mysql,文件,redis,我觉得性能也不是问题。我也不知其弊端在哪里,

有谁具体研究过,请帮我分析分析其利弊
也请大家有想法的各抒己见,我们一起讨论下

阅读 9.5k
评论
    12 个回答
    • 15.1k

    SESSION一般都依赖COOKIE来实现. Android和iOS开发中用到的HTTP客户端肯定也是支持cookie的,就像curl这种Linux库一样. 但是其不能做到像浏览器那样自动化,也就是说cookie的保存和使用都得Android和iOS开发者自己去实现,所以说还不如直接用token,把token放到GET或POST参数里发送就好. 保存时,Android和iOS开发者可以先对这个token进行加密如AES,然后存储到自己App的目录中. 加密的密钥定义在自己的App程序里,加密的向量可以用一个预定义随机数+无线网卡的MAC地址等设备唯一标识. 这样就算用户应用的token泄露了,拿到其他手机上也没用,因为加密后的token是设备相关的.

    服务器生成并返回给客户端的token,也是一个加密过的数据. 里面可以包含"用户名|用户盐|过期时间"这些数据. 加密是为了防止用户(攻击者)篡改和伪造token,并且实现强制过期.其中"用户盐"是用户表里的一个字段,是在用户注册或修改密码时生成的一个随机数.同理,你生成一个用于验证用户身份的cookie一样可以这样组织数据,服务器端拿数据时的区别只不过是$_GET['token']和$_COOKIE['token']的区别.

    最后提一些安全问题,放在GET参数(URL)里的token,会反映在浏览器的历史记录里(App一般没有这个问题),同时会反映在HTTP服务器如Nginx的日志记录里,POST参数则没有这些问题,所以把token放在POST里传输会更安全一些.