1. sessionjavascript
session和cookie的目的相同,都是为了克服http协议无状态的缺陷,但完成的方法不一样。session经过cookie,在客户端保存session id,而将用户的其余会话消息保存在服务端的session对象中,与此相对的,cookie须要将全部信息都保存在客户端。所以cookie存在着必定的安全隐患,例如本地cookie中保存的用户名密码被破译,或cookie被其余网站收集(例如:1. appA主动设置域B cookie,让域B cookie获取;2. XSS,在appA上经过javascript获取document.cookie,并传递给本身的appB)。
java
2. jwt:react
真正讲明白的一篇文章: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authenticationweb
0. 算法
23 Oct 2015数据库
jwt 不只可用于验证用户还可用于 server 间通讯验证api
app server 多是分布式的, 有不少 server, 在一个 server 上登陆了,
其余的没登录, 须要额外工具来解决这个问题(sticky sessions)浏览器
app 使用 RESTfull api 来获取数据, RESTful api 的原则是 stateless, 但使用 session, 使用 session 和 cookies 会引入 state; 另外, 当 API server 与 app server
多是两个 server, 须要 容许 CORS(Cross-Origin Resource Sharing), 可是 cookies 只能在同一个 domain 中使用缓存
app 可能须要下游服务, 每一个 server 都要处理 cookie(???)安全
JWT 方案不使用 session 基于 token.
用户注册以后, 服务器生成一个 JWT token返回给浏览器, 浏览器向服务器请求
数据时将 JWT token 发给服务器, 服务器用 signature 中定义的方式解码
JWT 获取用户信息.
一个 JWT token包含3部分:
1. header: 告诉咱们使用的算法和 token 类型
2. Payload: 必须使用 sub
key 来指定用户 ID, 还能够包括其余信息
好比 email, username 等.
3. Signature: 用来保证 JWT 的真实性. 可使用不一样算法
1. 和Session方式存储id的差别
Session方式存储用户id的最大弊病在于要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。通常而言,大型应用还须要借助一些KV数据库和一系列缓存机制来实现Session的存储。
而JWT方式将用户状态分散到了客户端中,能够明显减轻服务端的内存压力。除了用户id以外,还能够存储其余的和用户相关的信息,例如该用户是不是管理员、用户所在的分桶(见[《你所应该知道的A/B测试基础》一文](/2015/08/27/introduction-to-ab-testing/)等。
虽然说JWT方式让服务器有一些计算压力(例如加密、编码和解码),可是这些压力相比磁盘I/O而言或许是半斤八两。具体是否采用,须要在不一样场景下用数听说话。
2. http://blog.rainy.im/2015/06/10/react-jwt-pretty-good-practice/
区别(仔细揣摩)
##1.
这么基础的问题,竟然仍是没人说到点子上,最关键的一点是:
* Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端
其它细枝末节的区别,所有是由这一点形成的。
就没人想过为何token-based的authentication须要一堆secret key来干吗么?
由于状态信息所有是放在客户端,为了不被篡改,因而须要用密码学的方法来签名/加密。
能够本身去这里玩玩JWT的Debugger:
http://jwt.io/
一进去你就会注意到两点:
1. Token解码后就包含全部登录信息
2. Token你随便改一位都会提示无效
##2.
session 和 token 就是个词而已…… 广义来讲一切维护用户状态的技术都是session,一切动态生成的服务端有能力鉴别真假而自己无涵义的字符串都是token |
更多的详见:
http://www.slideshare.net/derekperkins/authentication-cookies-vs-jwts-and-why-youre-doing-it-wrong