安全-凭证

cookie

cookie是存储在浏览器中的键值对文本信息。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

• cookie流程：

1. 客户端首次请求服务器，浏览器不会携带cookie.
2. 服务器接收到请求后，如果请求中没有cookie，就会使用response向客户端浏览器颁发一个Cookie，客户端浏览器会把Cookie保存起来。
3. 当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

session

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。
如果浏览器禁用了cookie，则服务器无法使用session。

• session流程：

1. 浏览器首次登录服务器时，服务器会接收到浏览器请求并验证用户登录信息，校验成功则会在服务器中设置一个session，并响应一个session信息给浏览器。
2. 浏览器接收到响应，会将cookie信息保存起来。
3. 浏览器再次请求服务器时都会携带sessionid，服务器会根据sessionid自动验证session信息，验证成功，则能获取到session信息。

• 依赖于Cookie

1. 所有请求者的Session都会存储在服务器中，服务器如何区分请求者和Session数据的对应关系呢？
   答：在使用Session后，会在Cookie中存储一个sessionid的数据，每次请求时浏览器都会将这个数据发给服务器，服务器在接收到sessionid后，会根据这个值找出这个请求者的Session
2. 如果想使用Session，浏览器必须支持Cookie，否则就无法使用Session了。
3. 存储Session时，键与Cookie中的sessionid相同，值是开发人员设置的键值对信息，进行了base64编码，过期时间由开发人员设置

分布式环境下的cookie-session

Session-Cookie 在单节点的单体服务环境中是最合适的方案，但当需要水平扩展服务能力，要部署集群时就开始面临麻烦了，由于 Session 存储在服务器的内存中，当服务器水平拓展成多节点时，设计者必须在以下三种方案中选择其一：

• 牺牲集群的一致性（Consistency），让均衡器采用亲和式的负载均衡算法，譬如根据用户 IP 或者 Session 来分配节点，每一个特定用户发出的所有请求都一直被分配到其中某一个节点来提供服务，每个节点都不重复地保存着一部分用户的状态，如果这个节点崩溃了，里面的用户状态便完全丢失。
• 牺牲集群的可用性（Availability），让各个节点之间采用复制式的 Session，每一个节点中的 Session 变动都会发送到组播地址的其他服务器上，这样某个节点崩溃了，不会中断都某个用户的服务，但 Session 之间组播复制的同步代价高昂，节点越多时，同步成本越高。
• 牺牲集群的分区容忍性（Partition Tolerance），让普通的服务节点中不再保留状态，将上下文集中放在一个所有服务节点都能访问到的数据节点中进行存储。此时的矛盾是数据节点就成为了单点，一旦数据节点损坏或出现网络分区，整个集群都不再能提供服务。

通过前面章节的内容，我们已经知道只要在分布式系统中共享信息，CAP 就不可兼得，所以分布式环境中的状态管理一定会受到 CAP 的局限，无论怎样都不可能完美。但如果只是解决分布式下的认证授权问题，并顺带解决少量状态的问题，就不一定只能依靠共享信息去实现。这句话的言外之意是提醒读者，接下来的 JWT 令牌与 Cookie-Session 并不是完全对等的解决方案，它只用来处理认证授权问题，充其量能携带少量非敏感的信息，只是 Cookie-Session 在认证授权问题上的替代品，而不能说 JWT 要比 Cookie-Session 更加先进，更不可能全面取代 Cookie-Session 机制。

token

1. 当客户端第一次请求时，发送用户信息至服务器(用户名、密码)，服务器对用户信息使用HASH算法及密钥进行签名，再将这个签名和数据一起作为Token一起返回给客户端
2. 服务器不保存Token，客户端保存Token(比如放在Cookie里或者Local Storage里)
3. 当客户端再次发送请求时，在请求信息中将Token一起发给服务器
4. 服务器用同样的HS256算法和同样的密钥，对数据再进行一次签名，和客户端返回的Token的签名进行比较，如果验证成功，就向客户端返回请求的数据

JWT

JWT(全称：Json Web Token)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它使用了散列消息认证码HMAC。

HMAC

散列消息认证码（Hash-based Message Authentication Code，HMAC）。可以简单将它理解为一种带有密钥的哈希摘要算法，实现形式上通常是把密钥以加盐方式混入，与内容一起做哈希摘要。

HMAC 哈希与普通哈希算法的差别是普通的哈希算法通过 Hash 函数结果易变性保证了原有内容未被篡改，HMAC 不仅保证了内容未被篡改过，还保证了该哈希确实是由密钥的持有人所生成的。

1. 用户使用账号、密码登录应用，登录的请求发送到Authentication Server。
2. Authentication Server进行用户验证，然后创建JWT字符串返回给客户端。
3. 客户端请求接口时，在请求头带上JWT。
4. Application Server验证JWT合法性，如果合法则继续调用应用接口返回结果。

可以看出与token方式有一些不同的地方，就是不需要依赖redis，用户信息存储在客户端。所以关键在于生成JWT，和解析JWT这两个地方。

JWT的数据结构

JWT一般是这样一个字符串，分为三个部分，以"."隔开：

xxxxx.yyyyyyyyy.zzzzz
JWT头 JWT TOKEN 签名

Header

JWT第一部分是头部分，它是一个描述JWT元数据的Json对象，通常如下所示。

{
    "alg": "HS256",
    "typ": "JWT"
}

alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256），typ属性表示令牌的类型，JWT令牌统一写为JWT。

最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

Payload

JWT第二部分是Payload，也是一个Json对象，除了包含需要传递的数据，还有七个默认的字段供选择。

分别是，iss：发行人、exp：到期时间、sub：主题、aud：用户、nbf：在此之前不可用、iat：发布时间、jti：JWT ID用于标识该JWT。

如果自定义字段，可以这样定义：

{
    //默认字段
    "sub":"主题123",
    //自定义字段
    "name":"",
    "isAdmin":"true",
    "loginTime":"2021-12-05 12:00:03"
}

需要注意的是，默认情况下JWT是未加密的，任何人都可以解读其内容，因此如果一些敏感信息不要存放在此，以防信息泄露。

JSON对象也使用Base64 URL算法转换为字符串保存。

Signature

JWT第三部分是签名。是这样生成的，首先需要指定一个secret，该secret仅仅保存在服务器中，保证不能让其他用户知道。然后使用Header指定的算法对Header和Payload进行计算，然后就得出一个签名哈希。也就是Signature。

那么Application Server如何进行验证呢？可以利用JWT前两段，用同一套哈希算法和同一个secret计算一个签名值，然后把计算出来的签名值和收到的JWT第三段比较，如果相同则认证通过。

JWT的优点

• json格式的通用性，所以JWT可以跨语言支持，比如Java、JavaScript、PHP、Node等等。
• 可以利用Payload存储一些非敏感的信息。
• 便于传输，JWT结构简单，字节占用小。
• 不需要在服务端保存会话信息，易于应用的扩展。