使用Simple JWT提供认证服务（详细介绍access_token和refresh

使用Simple JWT提供认证服务（详细介绍access_token和refresh_token的使用）

文章目录

- 基本概念
- - JSON Web Token（JWT）
  - Simple JWT
- 主要用途
- Cookie、Session、Token的区别
- - Cookie
  - Session
  - Token
- Token续签
- access_token 和 refresh_token时效设置

基本概念

JSON Web Token（JWT）

JSON Web Token（JWT），又称为JSON令牌，是一种用于在网络应用之间安全地传输信息的开放标准（RFC 7519）。

它采用了一种紧凑的、自包含的方式来表示信息，通常用于身份验证和授权。
JWT的设计目标是确保信息的完整性和安全性，同时具备易于使用和传输的特点。

Simple JWT

Simple JWT为Django REST框架提供了一个JSON Web Token身份验证后端

主要用途

提供身份鉴别认证
标识用户登陆状态

Cookie、Session、Token的区别

Cookie

一开始HTTP是无状态的，用户访问完Web网站浏览完就无任何连接
随着用户需求的提升和技术的发展，用户希望以交互的形式进行网站访问，例如发表评论，记录生活，便出现Cookie的技术。

Cookie是一个保存在客户机中的简单的文本文件, 这个文件与特定的 Web 文档关联在一起, 保存了该客户机访问这个Web 文档时的信息, 当客户机再次访问这个 Web 文档时这些信息可供该文档使用。

以购物为例子
用户添加商品到购物车时，浏览器像服务器发送请求，服务器会查找到此商品到id并存储在Cooike中返回。浏览器将接收到的Cooike存储在本地，当下一次访问时会继续携带Cooike请求服务器。

但是随着购物车商品越来越多，请求的Cookie越来越多，请求压力也越大。同时我们会发现Cookie存放的信息本身就是服务器提供的，服务器本身有，我们为什么还要多才发送相同的数据？

Session

为了解决Cookie带来的问题，便出现出现了存储在服务器的Session

用户每次登陆，Session为其分配一个唯一的 sessionId，我们可以查到使用这个 sessionId的用户。而sessionId我们通过cookie返回给用户。
当后续再添加商品时我们通过携带的 sessionId的便可以知道是哪一个用户需要的商品

但是随着用户的增多，一台服务器不能满足我们的日常所需，我们会新增服务器，但是此时出现的问题是Session存储在哪个服务器，不能很好的支持分布式

Token

Token不存储在服务器端，所以无需考虑多台服务器Token的同步问题。
用户信息存储在Token中，我们每次只需要携带Token请求服务端我们就可以知道是哪个用户。
但是Token有效期不是永久的，当过期之后用户便无法通过认证，我们需要获取新的Token

Token在有效期内我们可以认为用户是登陆状态，当Token失效后我们就需要用户重新登录

Token续签

延长Token过期时间有两种方案

access_token
refresh_token

首次登陆
在这里插入图片描述
后续登陆

当 access_token 过期时，需要通过 refresh_token 来刷新，拿到新的 access_token 和 refresh_token

我们已经有了access_token便可以通过认证，为什么还需要refresh_token 呢？

我们只有输入账号密码通过验证之后才可以拿到access_token，access_token失效我们还需要再次输入账号密码重新登陆
但是有了refresh_token，我们就可以直接识别用户，无需再次输入账号密码便可以获取access_token

实际业务中，假设我们设置的access_token为1天，用户1天内无需输入密码，如果用户只使用1次后续很长一段时间不在使用，我们把这个用户标识为非活跃用户，后续某天再次使用系统需要重新登陆密码。如果用户在access_token有效的1天内每个一段时间访问，我们标识为活跃用户，当第二天token失效重新登陆密码会影响用户体验，此时我们如果使用refresh_token自动刷新用户就无需输入账号密码。

access_token 和 refresh_token的时效就需要设置不一致，当短的access_token 时效过了之后，发送时效长的 refresh_token 重新获取一个短时效access_token。
如果都过期，就需要重新登录了。