Question

Cookie-Session

Cookie-Session 方式是早期最常用的身份认证方式，直到现在很多 Web 网站依然使用这种方式。其认证流程是

• 用户在浏览器中输入账号密码登录；
• 服务端验证通过后，将用户信息保存在 Session 中并生成一个 Session ID；
• 然后服务端将 Session ID 放在 HTTP 响应头的 cookie 字段中；
• 浏览器收到 HTTP 响应后，将 cookie 保存在浏览器中，cookie 内容就是之前登录时生成的 Session ID；
• 用户再访问网站时，浏览器请求头就会自动带上 cookie 信息；
• 服务端接收到请求后，从 cookie 获取到 Session ID，然后根据 Session ID 解析出用户信息。

这种方案存在两个主要问题：

• 服务端的 Session ID 是直接存储在内存中的，在分布式系统中无法共享登录状态；
• cookie 是浏览器的功能，手机 App 等客户端并不支持 cookie，所以该方案不适用于非浏览器的应用。

第一个问题也是 Cookie-Session 方案应用于 Serverless 架构的主要问题，因为 Serverless 应用是无状态的，内存中的数据用完即销毁，多个请求间无法共享 Session。解决该问题也比较容易， 就是用一个共享存储来保存 Session 信息，最常见的就是 Redis，因为 Redis 是一个内存数据库，读写速度很快。

于是 Cookie-Session 的身份认证方案就发生了变化：

与早期方案不同，用户登录时，该方案会把用户信息保存在 Redis 中，而不是内存中，然后服务端依然会将 Session ID 返回给浏览器，浏览器将其保存在 cookie 中。而之后非登录的请求，浏览器依然会将包含 Session ID 的 cookie 放在请求头中发送给服务端，服务端拿到 Session ID 后，从 Redis 中查询出用户信息。这样就可以解决分布式、无状态的系统中用户登录状态共享问题。

不过这个方案依旧无法解决非浏览器场景的身份认证问题，所以 JWT 方案诞生了。

JWT

JWT 是（JSON Web Token）的简称，其原理是：

• 服务端认证通过后，根据用户信息生成一个 token 返回给客户端；
• 客户端将 token 存储在 cookie 或 localStorage 中；
• 之后客户端每次请求都需要带上 token，通常是将 token 放在 HTTP 请求头的 Authorization 字段中；
• 服务端接收到 token 后，验证 token 的合法性，并从 token 中解析出用户信息。

token 是个比较长字符串，格式为 Header.Payload.Signature ，由 . 分隔为三部分。下面是一个实际的 token 示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJqYWNrIiwiaWF0IjoxNjEwODg1MTcxfQ.KIduc-undaZ0z-Bt4wjGZIK5fMlx1auVHl_G1DvGDCw

可能有同学会担忧： token 是根据用户信息生成的，这样会不会泄露用户信息呢？其实不用担心，因为生成 token 的加密算法是不可逆的，并且 token 也可以设置过期时间，所以 token 字符串本身不会泄露用户信息。

基于 JWT ，客户端可以使用自己特有的存储来保存 token，不依赖 cookie，所以 JWT 可以适用于任意客户端。并且使用 JWT 进行身份认证，服务端就不用存储用户信息了，这样服务端就是无状态的。因此 JWT 这种身份认证方案，也非常适合 Serverless 应用。

接下来，就基于 JWT ，带你从 0 到 1 实现一个登录注册应用