鉴权基础扫盲：Session、Cookie、Token、JWT、OAuth 2.0核心概念辨析

002、鉴权基础扫盲：Session、Cookie、Token、JWT、OAuth 2.0核心概念辨析

昨天深夜调试一个第三方接口，对方突然要求从Session切换成Token验证，团队里几个小伙子对着文档折腾了三小时还没调通。我过去看了一眼日志，发现他们在HTTP头里把Token拼成了"Authorization: token xxxxx"，而对方要求的是"Bearer xxxxx"。这种看似细微的格式差异，背后其实是鉴权机制的理解偏差。今天咱们就彻底理清这些概念，下次遇到类似问题能一眼看穿本质。

从一次登录请求说起

用户在前端输入账号密码点击登录，这个请求到达服务端后，服务端需要记住“这个用户已经认证过了”。怎么记？最简单的办法就是在内存里建个表，把用户ID和登录状态存进去，返回给前端一个钥匙（比如session_id=abc123）。下次请求时前端出示这把钥匙，服务端查表确认身份。

这就是Session机制的核心——服务端存储状态。但问题来了：如果服务端是集群部署，用户第一次请求打到服务器A，第二次请求打到服务器B，B服务器上没有这个Session数据怎么办？于是得引入Session共享方案，比如Redis集中存储。这时候Session的维护成本就上来了。

Cookie：不是鉴权方案，是载体

很多人把Cookie和Session混为一谈。严格来说