主流的用户身份认证方案？都在这里！
前言
在现在的互联网服务中，用户认证是至关重要的环节。其一般流程大致如下：
用户向服务器发送用户名和密码，以发起登录请求。服务器对用户提供的信息进行验证。验证通过后，在当前会话（session）中保存相关数据，例如用户角色、登录时间等关键信息。服务器向用户返回一个唯一的 session_id，并将其写入用户的 Cookie 中。用户后续的每一次请求，都会通过 Cookie 将 session_id 传递回服务器。服务器接收到 session_id 后，查找前期保存的数据，从而确定用户的身份，进而为用户提供相应的服务和权限。
然而，这种传统的认证模式在扩展性方面存在一定的局限性。在单机环境下，它运行良好，但一旦涉及服务器集群或跨域的服务导向架构，就需要解决 session 数据共享的问题，确保每台服务器都能够读取和使用 session 数据。
例如，假设 A 网站和 B 网站属于同一家公司的关联服务，我们期望用户在其中一个网站成功登录后，访问另一个网站时能够自动登录。那么，如何实现这一功能呢？
方案一：Session 数据持久化
一种可行的解决方案是将 session 数据持久化，例如将其写入数据库或其他持久存储层。这样，各种服务在收到请求后，都可以向持久层请求所需的数据。此方案的优点在于架构清晰，逻辑明确。但缺点也较为明显，其工程量相对较大。而且，如果持久层出现故障，将会导致单点失败，整个系统的稳定性将受到严重影响。
方案二：基于客户端存储的 JWT 方案
另一种创新的方案是服务器不再保存 session 数据，而是将所有与用户相关的数据都保存在客户端。每次请求时，客户端将这些数据发回服务器。JWT（JSON Web Token）就是这种方案的典型代表。
HTTP 的无状态特性
我们都清楚，HTTP 是一种无状态（stateless）的协议。这意味着 HTTP 对于事务处理没有记忆能力，不会保存请求和响应之间的通信状态。每次有新的请求发送时，都会产生相应的新响应。协议本身并不保留之前的请求或响应报文的任何信息。这种设计的初衷是为了能够快速处理大量事务，确保协议的可伸缩性，从而使 HTTP 协议保持简洁高效。
然而，随着 Web 应用的不断发展，这种无状态的特性在某些场景下带来了诸多不便。以用户登录新浪微博为例，用户在登录页输入用户名、密码后进入首页。但由于 HTTP 无状态的特性，HTTP 无法知晓上一次的请求是否通过了验证，更无法获取当前用户的具体信息。
最直接的解决办法或许是在所有的请求中都附带用户名和密码。这种方法虽然在技术上可行，但会极大地增加服务器的负担（因为服务器需要针对每个请求都到数据库进行验证），同时也会给用户带来极差的体验，因为用户需要在每进入一个页面时都输入密码。
为了解决这些问题，各种身份认证机制应运而生，其中较为常见的有 Cookie-Session 机制和 JWT 机制。
Cookie-Session 机制
Cookie 简介
Cookie 是由 HTTP 服务器设置，并保存在浏览器中的小型文本文件，其内容以一系列的键值对形式呈现。在 Chrome 浏览器中，您可以通过开发者工具 -> Application -> Cookies 查看 Cookie 的详细信息。
以下简单介绍一些常见的 Cookie 字段含义：
Expires：指定 Cookie 的过期时间。默认情况下，Cookie 在用户关闭浏览器时过期。HttpOnly：此属性指示浏览器不要在除了 HTTP（或者 HTTPS)请求之外暴露 Cookie。通过 JavaScript 脚本无法访问到具有 HttpOnly 属性的 Cookie，这能有效防止 XSS（跨站脚本攻击）。Secure：当设置 Cookie 的 Secure 属性为 true 时，意味着 Cookie 仅能在安全/加密连接（如 HTTPS）下使用。也就是说，只有在 HTTPS 协议下，Cookie 才能被上传到服务器，而在 HTTP 协议下无法上传。
Cookie 的传递过程
浏览器向某个 URL 发送请求。对应的服务器收到该 HTTP 请求后，生成要发送给浏览器的 HTTP 响应。在响应头中添加 Set-Cookie 字段，其值为要设置的 Cookie 内容。浏览器收到来自服务器的 HTTP 响应。浏览器在响应头中发现了 Set-Cookie 字段，便会将该字段的值保存在内存或硬盘中。当下一次向该服务器发送 HTTP 请求时，会将服务器设置的 Cookie 附加在 HTTP 请求的 Cookie 字段中。服务器收到这个 HTTP 请求后，若发现请求头中有 Cookie 字段，就知道已经处理过这个用户的请求了。过期的 Cookie 会被浏览器自动删除。
Session 介绍
与存储在浏览器中的 Cookie 不同，Session 数据是存储在服务器端的，这样可以避免在客户端存储敏感信息。而且，Session 的存取方式更为灵活，能够存储任何类型的数据，而 Cookie 只能保存 ASCII 字符串，如果需要存取 Unicode 字符或二进制数据，则需要先进行编码。通常，Session 会与 Cookie 配合使用，这就是接下来要探讨的 Cookie-Session 机制。
Cookie-Session 身份验证机制的工作流程
用户输入登录信息。服务端验证登录信息的正确性。如果验证通过，就在服务器端为该用户创建一个 Session，并将 Session 数据存入数据库。服务器端向客户端返回带有 sessionID 的 Cookie。客户端接收到服务器端发来的请求后，在响应头中看到 Set-Cookie 字段，将 Cookie 保存起来。在接下来的请求中，客户端都会带上这个 Cookie。服务器将收到的 sessionID 与数据库中的进行匹配，如果匹配有效，则处理该请求。如果用户登出，Session 会在客户端和服务器端都被销毁。
Cookie-Session 机制的缺陷
扩展性不佳：在多服务器的环境下，如何共享 Session 数据成为难题。例如，当用户首次访问的是服务器 A，而第二次请求被转发到服务器 B 时，服务器 B 无法获取用户的状态信息。安全性欠佳：攻击者可能利用本地 Cookie 进行欺骗和 CSRF（跨站请求伪造）攻击。对服务器性能有影响：由于 Session 数据保存在服务器端，如果短时间内有大量用户登录，会占用大量服务器内存，影响服务器性能。跨域问题：Cookie 受到同源策略的限制。
JWT 机制
JWT 的组成
JWT 由三个部分组成：header（头部）、payload（负载）和 signature（签名），每个部分之间使用 . 分隔。其中，header 和 payload 使用 Base64URL 进行编码：
base64UrlEncode(header).base64UrlEncode(payload).signature
Header（头部）
header 部分是一个 JSON 对象，用于描述 JWT 的元数据，例如：
{
"typ": "JWT",
"alg": "HS256"
}
其中，typ 表示这是一个 JWT 对象，alg 表示用于创建签名的 Hash 算法，这里使用的是 HMAC-SHA256 算法。
Payload（负载）
payload 部分同样是一个 JSON 对象，实际需要传递的数据就存放在这里。除了使用官方提供的七个字段之外，还可以自定义私有字段，例如：
{
"sub": "title",
"name": "Yeoman"
}
需要注意的是，JWT 默认是不加密的，任何人都可以读取其中的内容，因此不要在 payload 中存放敏感信息。
Signature（签名）
signature 是对前两个部分的签名，用于防止数据被篡改。其生成过程如下：
data = base64urlEncode( header ) + "." + base64urlEncode( payload );
signature = Hash( data, secret );
首先，将使用 Base64URL 编码的 header 和 payload 用 . 连接起来，然后使用 header 中指定的 Hash 算法（如上述的 HMAC-SHA256），结合一个密钥对这个字符串进行 Hash 运算，得到 signature。
JWT 的工作流程
前端将自己的用户名和密码发送到后端的接口。后端核对用户名和密码。如果正确，将用户的一些信息作为 payload，生成 JWT。后端将 JWT 作为登录成功的返回结果返回给前端。前端可以将其结果保存在 localStorage 或 sessionStorage 中，登出时删除 JWT 即可。（建议不要保存在 Cookie 中，因为使用 Cookie 无法设置 HttpOnly 属性，且存在跨域问题。）每一次请求都将 JWT 放在 HTTP 请求头中的 Authorization 字段中，格式为 Authorization: Bearer
JWT 的特点
JWT 默认是不加密的，因此其安全性相对较低。JWT 的主要目的是验证来源的可靠性，而不是保护数据或防止未经授权的访问。可以将其类比为一张电影票，它只能验证电影票的真伪以及包含一些基本信息，但他人也可能使用您的电影票。一旦 JWT 被暴露，任何人都可能获得相应的权限。为了降低被盗用的风险，JWT 的有效期应设置得相对较短。对于一些重要的权限，使用时应再次对用户进行认证。JWT 最大的缺点是 token 过期处理问题。由于服务器不保存 Session 状态，因此无法在使用过程中废止或更改权限。也就是说，一旦 JWT 签发，在到期之前它始终有效，除非服务器部署额外的逻辑来处理。
几个case
同源策略限制的内容
同源策略限制的内容包括：Cookie、LocalStorage、SessionStorage、IndexedDB 等存储性内容；DOM 节点；Ajax 发送请求后，结果被浏览器拦截。
Cookie 和 Session 的区别
存取方式：Cookie 只能保存 ASCII 字符串，如需存取 Unicode 字符或二进制数据，需先进行编码。Session 则可以存取任何类型的数据。隐私策略：Cookie 存储在浏览器中，Session 存储在服务器上。服务器压力：Session 保存在服务器上，每个用户都会产生一个 Session。在并发访问用户众多的情况下，会产生大量的 Session，消耗大量服务器内存。
分布式情况下的 Session 和 Token
我们已经了解到 Session 是有状态的，通常存储于服务器的内存或硬盘中。当服务器采用分布式或集群架构时，Session 就会面临负载均衡的问题。
在大型互联网公司中，为了支撑巨大的流量，后端往往需要多台服务器共同来处理前端用户的请求。如果用户在 A 服务器登录，第二次请求却被分发到服务 B，就可能出现登录失效的问题。
针对分布式 Session，一般有以下几种解决方案：
Nginx 的 ip_hash 策略：服务端使用 Nginx 作为代理，每个请求按照访问 IP 的哈希值进行分配。这样，来自同一 IP 的请求会固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次请求却分发到服务器 B 的情况。Session 复制：任何一个服务器上的 Session 发生变更（如增加、删除、修改），该节点会将这个 Session 的所有内容序列化，然后广播给其他所有节点。共享 Session：将服务端设置为无状态，使用缓存中间件来统一管理用户的 Session 等信息，确保分发到每一个服务器的响应结果都一致。
综合考虑，建议采用第三种方案。
而 Token 是无状态的，Token 字符串中保存了所有的用户信息。客户端登录时向服务端传递信息，服务端接收后将用户信息加密生成 Token 并返回给客户端。客户端将 Token 存放在 localStorage 等容器中。客户端每次访问时都传递 Token，服务端对 Token 进行解密，从而确定用户身份。通过这种 CPU 加解密的方式，服务端无需存储 Session，节省了存储空间，有效地解决了负载均衡和多服务器环境下的问题。这种方法也就是 [JWT(Json Web Token)]