认证、授权、鉴权凭证 cookie、session、token、JWT

yuran1

已于 2023-04-09 17:35:03 修改

阅读量299

点赞数 1

分类专栏：前端文章标签：服务器运维网络交互

于 2023-01-14 12:56:45 首次发布

本文链接：https://blog.csdn.net/yuran1/article/details/128683742

版权

前端专栏收录该内容

6 篇文章 0 订阅

订阅专栏

认证authentication，指的是验证访问者的身份

常见认证方法

用户名密码认证
短信验证码认证
邮箱验证码认证
扫码认证
人脸识别或者其他生物特征识别认证

授权authorization，指的是用户通过身份认证后，能够访问指定的某些资源

常见授权模型—3种

ACL（Access Control List）：ACL中包含用户、资源、资源操作三个关键内容。通过将资源以及资源操作授权给用户，使得用户具有操作某项资源的权限
RBAC（Role-Based Access Control）：对用户进行角色分类，通过角色来判断用户是否拥有对某种资源的资源操作权限
ABAC(Attribute Base Access Control)：基于计算一个或者一组属性是否满足某条件来判断是否有操作权限

鉴权凭证，首次验证用户身份成功后，服务端会发给客户端一个用户凭证，表示这个用户已经通过认证，之后的请求，用户只需要携带上这个凭证来证明自己的身份就好。

鉴权凭证分类—根据存储方式

纯ccokie
基于单机的session
需要存储的token
不需要存储的JWT

1. 纯cookie

HTTP协议是无状态的，指的是协议对事务处理没有记忆能力，服务器不知道客户端是什么状态，也就是说打开一个服务器上的网页和上一次打开这个服务器上的网页之间是没有任何联系的。

这里选用一个知乎上的回答，形象地说明【无状态】到底是啥意思，哈哈哈

有状态：

A（浏览器）：你今天中午吃的啥？

B（服务器）：吃的大盘鸡。

A（浏览器）：味道怎么样呀？

B（服务器）：还不错，挺好吃的。

无状态：

A（浏览器）：你今天中午吃的啥？

B（服务器）：吃的大盘鸡。

A（浏览器）：味道怎么样呀？

B（服务器）：？？？啊？啥？啥味道怎么样？

是不是感觉在“无状态”下，通信过程变得鸡肋，为了解决这个问题，cookie就是出现了

cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再次发起请求时被携带发送给服务器。因此cookie是由服务器创建的，但存储在客户端。因而上面的浏览器端和服务器的交互过程就变成了这样

A（浏览器）：你今天中午吃的啥？

B（服务器）：吃的大盘鸡。--->服务器创建cookie,回应时携带cookie给浏览器

A（浏览器）：味道怎么样呀？--->携带cookie给服务器

B（服务器）：还不错，挺好吃的。--->服务器根据cookie知道浏览器问的是大盘鸡

对于鉴权凭证来说：使用纯Cookie的方式，用户在登录之后，服务器将用户的id或者用户账户发送到客户端，客户端保存Cookie，客户端每次请求时自动带上保存的Cookie，服务器接收到请求时，取出Cookie的用户id来鉴别用户。但是这种方式较为不安全，因为用户id、用户名这些信息都暴露在Cookie里。

2. 基于单机的session

在web中，用户打开一个浏览器，点击多个超链接，访问服务器多个web资源，然后关闭浏览器，上述整个过程称为“会话”。而session是一种记录服务器和客户端会话状态的机制，包括会话所需要的属性及配置信息，被称为“会话控制”。

当访问某个网页的时候，会在服务器端的内存中开辟一块内存，这块内存就叫做session对象。默认情况下，一个浏览器独占一个session对象，且一个session对象拥有一个独一无二的ID。当服务器端创建完session对象后，会把session ID返回给客户端，客户端保持当前浏览器不变再次去访问服务器端时，就会把session ID传递给服务器，服务器根据ID找寻对应的session对象，为用户提供相应服务。

将session从服务端传递给客户端的方式，主要有两种：

1.借助cookie传递：将session ID放在cookie里面

2.重写URL：通过response.encodeURL( )方法在URL后面加上sessionID。这样的话，即使禁用cookie也可以使用session了。

验证session正确性的方式，主要有两种：

1.使用时间戳验证：即服务器端在生成Session时，会将Session和一个时间戳一起发送给客户端，客户端收到Session和时间戳后，将Session和时间戳一起发送给服务器，服务器收到Session和时间戳后，会对时间戳进行验证，如果时间戳有效，则表明Session是有效的。

2.使用签名验证：即服务器端在生成Session时，会将Session和私钥一起使用数字签名的方法生成签名，并将签名和Session一起发送给客户端，客户端收到签名和Session后，将签名和Session一起发送给服务器，服务器收到签名和Session后，会使用公钥对Session和签名进行验证，如果验证通过，则表明Session是有效的。

session的缺点：由于session是保存在服务器中的，如果采用分布式部署应用，则会出现session不能共享的问题，很难扩展。