系统登录认证流程对比(cookie方式与jwt)

川长思鸟来 2022-11-21 11:36 204阅读 0赞

# 系统登录认证流程对比(cookie方式与jwt) #

### 文章目录 ###

*  系统登录认证流程对比(cookie方式与jwt)
 *  背景知识：
 *   *  Authentication和Authorization的区别：
 *  一、cookie方式登录认证
 *  二、JWT(Json Web Token)方式登录认
 *  三、区别优缺点
 *   *  jwt的优点：
     *  jwt的缺点：
     *  总结:

--------------------

# 背景知识： #

## Authentication和Authorization的区别： ##

Authentication：用户认证，指的是验证用户的身份，例如你希望以小A的身份登录，那么应用程序需要通过用户名和密码确认你真的是小A。

Authorization：授权，指的是确认你的身份之后提供给你权限，例如用户小A可以修改数据，而用户小B只能阅读数据。

由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态。

目前主流的用户认证方法有基于token和基于session两种方式。

# 一、cookie方式登录认证 #

步骤:  
  
1.用户向服务器发送用户名和密码。  
  
2.服务器验证后，相关数据（如用户角色等）将保存在当前会话(session)中。  
  
3.服务器向用户返回sessionId会写入到用户的Cookie。  
  
4.用户后续请求都将通过在Cookie中取出sessionId传给服务器。  
  
5.服务器收到sessionId并对比之前保存的数据，确认用户的身份。  
  
![cookie方式登录认证][cookie]

# 二、JWT(Json Web Token)方式登录认 #

JWT(Json Web Token)  
  
数据结构：其中第一段为 header(头)，第二段为 payload (负载)，第三段为signature(签名)  
![JWT(Json Web Token)][JWT_Json Web Token]  
步骤:  
  
1.用户输入其登录信息

2.服务器验证信息是否正确，并返回已签名的token

3.token储在客户端，例如存在local storage或cookie中

4.之后的HTTP请求都将token添加到请求头里

5.服务器解码JWT，并且如果令牌有效，则接受请求

6.一旦用户注销，令牌将在客户端被销毁，不需要与服务器进行交互一个关键是，令牌是无状态的。后端服务器不需要保存令牌或当前session的记录。  
![基于JWT方式][JWT]

# 三、区别优缺点 #

基于session和基于jwt的方式的主要区别就是用户的状态保存的位置，session是保存在服务端的，而jwt是保存在客户端的。

## jwt的优点： ##

1.  可扩展性好

应用程序分布式部署的情况下，session需要做多机数据共享，通常可以存在数据库或者redis里面。而jwt不需要。

1.  无状态

jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

## jwt的缺点： ##

1.  安全性

由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。

1.  性能

jwt太长。由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。

1.  一次性

无状态是jwt的特点，但也导致了这个问题，jwt是一次性的。想修改里面的内容，就必须签发一个新的jwt。

（1）无法废弃

通过上面jwt的验证机制可以看出来，一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。

（2）续签

如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变jwt的有效时间，就要签发新的jwt。最简单的一种方式是每次请求刷新jwt，即每个http请求都返回一个新的jwt。这个方法不仅暴力不优雅，而且每次请求都要做jwt的加密解密，会带来性能问题。另一种方法是在redis中单独为每个jwt设置过期时间，每次访问时刷新jwt的过期时间。

可以看出想要破解jwt一次性的特性，就需要在服务端存储jwt的状态。但是引入 redis 之后，就把无状态的jwt硬生生变成了有状态了，违背了jwt的初衷。而且这个方案和session都差不多了。

## 总结: ##

适合使用jwt的场景：

1.有效期短  
2.只希望被使用一次  
比如，用户注册后发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时之内激活），不能被篡改以激活其他可能的账户，一次性的。这种场景就适合使用jwt。

而由于jwt具有一次性的特性。单点登录和会话管理非常不适合用jwt，如果在服务端部署额外的逻辑存储jwt的状态，那还不如使用session。基于session有很多成熟的框架可以开箱即用，但是用jwt还要自己实现逻辑。

转载于:https://www.cnblogs.com/yuanrw/p/10089796.html

[cookie]: /images/20221120/c43e589a8e8941ecb8f4b7b020d7cecc.png
[JWT_Json Web Token]: /images/20221120/8f8d3c43d2244ae38254b8122ec21021.png
[JWT]: /images/20221120/e85e96ea4e194e93a90eba6df02208af.png