欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

cookie session token

网络 water 150℃ 0评论

最近有个登录认证的需求, 就去搜查了下相关技术理念, 发现网上很多人对于标题中的这三个玩意儿并没有达成很一致的共识, 也就是说概念理解各有偏差. 所以经过一阵搜索逛论坛逛社区, 准备总结一下, 可能会有偏差, 望指正(鞠躬)

这三个大致都是一个作用:

让服务器端能知道请求的是谁, 以对应相应状态(比如用户已登录或用户不存在)

为什么产生:

HTTP是无状态的

cookie

状态保存在客户端, 或与服务器端合作

最没有, 或者说最少争议的, 定义最明确, 理解最统一的就是cookie了, 小饼干, 名字很cute.

直接来看标准, RFC2109 => RFC2965 => RFC6265, 看最新的:HTTP State Management Mechanism​tools.ietf.org

cookie的实质:

http头里的字段, 键值对形式, 或是单个的一个值

Set-Cookie 提供给服务器, 发送给用户, 用以设置cookie(服务器递过来一袋小饼干)
Cookie 用户请求服务器时携带cookie(服务器, 看! 这是我的小饼干)

从格式上来讲很简单: 键值对, 分号隔开

有一些专用的键值, 用以控制cookies的行为, 比如:

Expires 过期日期
Max-age 存活时间
Domain 对应的域, 可以设置以供多个同域名主机共享cookie, 或限制cookie可使用的域
Path 控制哪些路径的页面可以访问cookie
Secure 可以http传输或只能https, 防中间人攻击
HttpOnly 设置以禁用js的Document.cookie

API, 防XSS

cookie的使用:

传统地, 把一些简单的用户信息存储在cookie里, 浏览器存cookie有大小数量限制:

At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie’s name, value, and attributes).

At least 50 cookies per domain.

At least 3000 cookies total.

日常使用么, 自动登录什么的, 账号密码存cookie, 然后前端js里去判断cookie里有没有账号密码, 有就自动帮你填了提交, 免得你费力.

session

状态保存在服务器端

session这个东西就不是很清晰的一个实体了, 是一个抽象概念. 这实际是一种理念, 或者说是模式方法, 用来保存认证用户信息.

翻译过来是”会话”, 指代session这一模式, 当然也可能指代具体的数据库里保存的用户信息, 容易搞混, 这里指的是这种模式.

怎样一种模式呢?

服务器端存储用户数据信息. 这么多用户想要知道谁是谁, 每个必须有个名字, 或者说是id, 所谓”session id”(你可能看到过这个叫法). 用户先请求, 然后服务器生成session id(如果用户没有携带, 或已过期)并返还给用户, 用户留着, 以后每次请求, 带上这个”session id”, 然后服务器拿来往数据库(或者放内存, 这个视具体应用而定)里一搜, 找到该用户及其相应的信息(有时session id集中存放, 与数据分开, 用户数据分开放在集群里), 比如: 现在对应的用户是登录状态还是超时登出了什么的.

状态信息存储在服务器端, 用户只需留存一个”session id”. 大多数时候通过cookie传递存放, 当然也可以ajax传, 存Local Storage或Session Storage或IndexDB或Web SQL, 反正只要用户拿到并存着就行, 甚至可以用URL重写的方式传递.

所以说session是一种模式.

当然问题不少, 比如使用集群时怎么同步数据的问题, 像刚才括号里说的session id集中存放, 万一集中存的数据出事了怎么办, 等等, 但session用的还是很广泛的.

token

相较于前两个, token一般用于短期的验证

token翻译过来是”令牌”

token是服务器在用户登录后返还给用户的

token是无状态的, 用以在一段时间内免于重复登录, 过了时间就失效

怎么理解token, 我们来对登录这件事进行一个逻辑上的抽象:

登录这一行为, 是信任的传递
先用账号密码作为让服务器信任的凭据, 是用户主动希望获得服务器的信任.
而使用token, 是服务器表明对用户的信任

所以, 就像令牌一样, 当用户传递过来后(放在http的Authorization请求头), 服务器需要做的只是验证令牌的真假(将验证账号密码转换为验证令牌真假)

怎么知道这令牌真假呢? 就是保证令牌的数据完整性, 这就变成了验证数据完整性, 基本思路:

生成:
加密函数A(数据A + 密钥A) => 签名A
token = 数据A + 签名A
验证:
token => 数据A, 签名A
加密函数A(数据A + 密钥B) => 签名B
签名B == 签名A ? 验证成功 : 验证失败

所以验证成功的关键是

数据A未被更改
密钥B是对应的正确密钥(即密钥A)

这个过程由服务器完成, 密钥由服务器保存, 密钥问题解决

所以, 这就单一控制了变量数据A, 以确保了数据完整性

所有这些需要自己找加密函数, 自己制作token格式吗?

不用, 已经有现成的标准化token格式了

详见标准RFC7519JSON Web Token (JWT)​tools.ietf.org

JWT, 一种数据格式, 方便用作token, 实际应用理念就是如上所述, 这是官网JWT.IO​jwt.io

图标

总结, cookie是一种实体, 而 session 和 token 都是一种用以验证的模式.

通过写完这篇文章自己也清楚了不少, 以后不用被网上各种可信度存疑的论断轻易左右了

转载请注明:学时网 » cookie session token

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!