Cookie 和 Session
Session 和 Cookie 主要用来识别登录者身份的,默认通过 SessionID 唯一编号进行验证。Session 是在服务器端保存的一个数据结构,用来跟踪用户的状态,也可以保存用户相关的一些数据,可以保存在内存、缓存、数据库等存储结构中。Cookie 是客户端保存用户信息的一种机制。
Cookie
当客户端第一次发出请求,请求服务器时,如果服务器需要记录该用户状态,就会使用 response 向客户端浏览器响应回一个Cookie。客户端会把 Cookie 保存起来,保存在浏览器的内存中。
Cookie 是服务器发送到浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常,它用于告知服务端两个请求是否来自同一用户,如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面:
会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
个性化设置(如用户自定义设置、主题等)
浏览器行为跟踪(如跟踪分析用户行为等)
Session
每个用户访问服务器都会建立一个 Session,当用户与服务器建立连接的同时,服务器会自动为其分配一个SessionId,用于辨别用户。
Session 代表着服务器和客户端一次会话的过程。Session 对象(key-value形式)存储特定用户会话的状态(实际上和 Cookie 类似,都是为了存储用户相关的信息)。这样,当用户多次请求服务器时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。当客户端关闭会话,或者 Session 超时失效时会话结束。
Session 与 Cookie 的区别
作用范围不同。Cookie 保存在客户端(浏览器),Session 保存在服务器端。
存取方式的不同。Cookie 只能保存 ASCII,Session 可以存任意数据类型,一般情况下我们可以在 Session 中保持一些常用变量信息,比如说 UserId 等。
有效期不同。Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭或者 Session 超时都会失效。
隐私策略不同,Cookie 存储在客户端,比较容易遭到不法获取,早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取;Session 存储在服务端,安全性相对 Cookie 要好一些。
存储大小不同。单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie。
用户第一次请求服务器的时候,服务器根据用户提交的相关信息,创建对应的 Session ,请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器,浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入到 Cookie 中,同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候,请求会自动判断此域名下是否存在 Cookie 信息,如果存在自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作。
token
token 的全名叫 JSON Web Token
,缩写为 JWT
。
首先我们已经知道 cookie 和 session 一个存储在客户端,一个存储在服务端,并且通过验证内部的 sessionId 来实现用户的身份验证。之所以需要这种验证,主要还是因为 HTTP 的无状态特点,以至于用户每个页面切换时,都需要进行登陆,就很麻烦了。但是 cookie 和 session 可以帮助我们实现这种身份验证。
那么既然有了 cookie 和 session,为什么还需要 token 呢?
这里我们先不谈 session,因为它是存储在服务端的。cookie 和 token 是存储在客户端的,我们就先谈一谈 cookie 的不足之处。
cookie 是小文本文件,大小只有 4KB,很显然它存储的内容是十分有限的,一般也就是 key-value 形式保存一下我们的身份信息。
如果遇到跨域问题,cookie 是无法发送的。(除非我们通过设置客户端和服务端的 header 实现,包括 withCredentials、 Access-Control-Allow-Credntials 和 Access-Control-Allow-Origin)
cookie 不能存储敏感信息,因为 cookie 能够被客户端篡改。
session 的不足
- session 会存储在服务端,每一个用户都会对应一个自己的用户信息,如果用户量非常大,这会增加服务器的负载。
2.如果存在多个服务器,如负载均衡时,每个服务器的状态表必须同步,否则就无法实现身份验证。
token结构
实际上就类似于 HTTPS 的签名方式帮助服务器实现校验。token 由三部分构成:头部、负载和签名。
头部:存储 token 的类型和签名算法(如类型是 JWT,加密算法是 HS256)
负载:存储要存储的信息,如用户账号、姓名、昵称等。
签名:签名就是由指定的加密算法,将转义后的头部和负载,加上密钥一起加密得到的。
最后把这三部分连接起来就可以得到一个 token 了。
token认证流程
客户端使用用户名和密码请求登陆。
服务端收到请求后,去验证用户名和密码。
验证成功后,服务端签发一个 token,发送给客户端。
客户端收到 token 后会把它存储起来,比如放在 cookie 中获 localStorage 中。
客户端每次发送请求时都需要带着服务端签发的 token(把 token 放在 HTTP 的 header 中)。
服务端收到请求后,需要验证请求里带有的 token(通过解密算法解密),验证成功则返回对应的数据。
token 具有加密签名,而 cookie 和 session 是没有的。token 能存储的数据较多,而 cookie 仅有 4 KB。此外,token 还支持跨域认证的,而 cookie 是不允许的。
token 和 cookie 、session 的区别总结如下:
token 大小相较于 cookie 更大,能够存储更多信息。
token 支持跨域认证,而 cookie 不可以,需要客户端和服务端一起设置一些 header 才行。
token 具有加密签名,相比 cookie 更加安全。
token 是无状态的,存储在客户端本地,无需像 session 一样存储在服务器中增加内存压力。
token 利用解密的计算时间换取 session 在服务端的存储空间,并且不需要频繁的查询数据库。