基于Express的Session、JWT认证机制

第一章、Web 开发模式

1.1、服务端道染的传统Web开发模式

1）服务端渲染的概念：

服务器发送给客户端的HTML页面，是在服务器通过字符串的拼接，动态生成的。因此，客户端不需要使用Ajax这样的技术额外请求页面的数据。

2）优缺点

优点：

①前端耗时少。因为服务器端负责动态生成HTML内容，浏览器只需要直接渲关闭。尤其是移动端，更省电。

②有利于SEO。因为服务器端响应的是完整的HTML页面内容，所以爬虫更容易爬取获得信息，更有利于SEO。

缺点：

①占用服务器端资源。即服务器端完成HTML页面内容的拼接，如果请求较多，会对服务器造成一定的访问压力。

②不利于前后端分离，开发效率低。使用服务器端渲染，则无法进行分工合作，尤其对于前端复杂度高的项目，不利于项目高效开发。

1.2、前后端分离的新型Web开发模式

1）前后端分离的概念：

依赖于Ajax技术的广泛应用。简而言之，前后端分离的Web开发模式，就是后端只负责提供API接口，前端使用Ajax调用接口的开发模式。

2）优缺点

优点：

①开发体验好。前端专注于UI页面的开发，后端专注于api的开发，且前端有关闭择性。

②用户体验好。Ajax技术的广泛应用，极大的提高了用户的体验，可以轻松实现页面的局部刷新。

③减轻了服务器端的渲染压力。因为页面最终是在每个用户的浏览器中生成的。

缺点：

①不利于SEO。因为完整的HTML页面需要在客户端动态拼接完成，所以爬虫对无法爬取页面的有效信息。（解决方案：利用Ve、React 等前端框架的SSR（server side render）技术能够很好的解决SEO问题！）

第二章、身份认证

2.1、身份认证

身份认证（Authentication）又称“身份验证”、“鉴权”，是指通过一定的手段，完成对用户身份的确认。

在Web开发中，也涉及到用户身份的认证，例如：各大网站的手机验证码登录、邮箱密码登录、二维码登录等。

2.2、为何要身份认证

2.3、不同开发模式下的身份认证

对于服务端道染和前后端分离这两种开发模式来说，分别有着不同的身份认证方案：

①服务端渲染推荐使用Session认证机制

②前后端分离推荐使用JWT 认证机制

第三章、Session认证机制

3.1、HTTP协议的无状态性

了解HTTP协议的无状态性是进一步学习Session认证机制的必要前提。

HTTP协议的无状态性，指的是客户端的每次HTTP请求都是独立的，连续多个请求之间没有直接的关系，服务器不会主动保留每次HTTP请求的状态。

3.2、如何突破HTTP无状态的限制

使用Cookie技术

3.3、什么是Cookie

Cookie 是存储在用户浏览器中的一段不超过4KB的字符串。它由一个名称（Name）、一个值（Value）和其它几个用于控制 Cookie有效期、安全性、使用范围的可选属性组成。

不同域名下的Cookie各自独立，每当客户端发起请求时，会自动把当前域名下所有未过期的Cookie一同发送到服务器。

Cookie的几大特性：

①自动发送

②域名独立

③过期时限

④4KB限制

3.4、Cookie在身份认证中的作用

客户端第一次请求服务器的时候，服务器通过响应头的形式，向客户端发送一个身份认证的 Cookie，客户端会自动将Cookie保存在浏览器中。

随后，当客户端浏览器每次请求服务器的时候，浏览器会自动将身份认证相关的Cookie，通过请求头的形式发送给

3.5、Cookie不具有安全性

由于Cookie是存储在浏览器中的，而且浏览器也提供了读写 Cookie的APl，因此Cookie很容易被伪造，不具有安全性。因此不建议服务器将重要的隐私数据，通过Cookie的形式发送给浏览器。

注意：千万不要使用Cookie 存储重要且隐私的数据！比如用户的身份信息、密码等。

3.6、提高身份认证的安全性

这种“会员卡+刷卡认证”的设计理念，就是Session 认证机制的精髓。

3.7、Session的工作原理

登录成功后，用户登录信息存储在服务器的内存中，同时生成Cookie字符串

第四章、在Express中使用Session 认证

4.1、安装express-session中间件

在Express项目中，只需要安装express-session中间件，可在项目中使用Session认证

npm install express-session

4.2、配置 express-session中间件

通过app.use()来注册 session中间件，

4.3、向session中存数据

当express-session中间件配置成功后，即可通过req.session来访问和使用session对象，从而存储用户的关键信息：

4.4、从session中取数据

4.5、清空session

req.session.destory()

const express = require('express')
const app = express()
var session = require('express-session')
app.use(session({   //1、配置 express-session中间件
  secret:'wl',   //负责对session加密
  resave:false,
  saveUninitialized:true
}))
app.use(express.static('../public'))
app.post('/api/login',(req,res)=>{
  if(req.body.username !== 'admin' || req.body.password !== '000000'){
    return res.send({status:1,msg:'登录失败'})
  }
  req.session.user = req.body   //2、将登录成功的用户信息存到session
  req.session.islogin = true   //登录状态
  res.send({status:0,msg:'登录成功'})
})
//获取用户姓名的接口
app.get('api/username',(req,res)=>{
  //3、从session中获取用户名称，响应给客户端
  if(!req.session.islogin){
    return res.send({status:1,msg:'fail'})
  }
  res.send({
    status:0,
    msg:'sccess',
    username:req.session.user.username
  })
})
//退出登录接口
app.post('/api/logout',(req,res)=>{
  //4、清空session信息req.session.destory()
  req.session.destory()
  res.send({
    status:0,
    msg:'退出登录成功'
  })
})
app.listen(80,function(){
  console.log('http://127.0.0.1')
})

cookie与session的结合
有两种存储方式
①、存储在服务端
通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。
②、将session数据加密，然后存储在cookie中
这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。
flask中使用cookie和session
①cookies:
在Flask中操作cookie，是通过response对象来操作，可以在response返回之前，通过response.set_cookie来设置，这个方法有以下几个参数需要注意：

• key：设置的cookie的key。
• value：key对应的value。
• max_age：改cookie的过期时间，如果不设置，则浏览器关闭后就会自动过期。
• expires：过期时间，应该是一个datetime类型。
• domain：该cookie在哪个域名中有效。一般设置子域名，比如cms.example.com。
• path：该cookie在哪个路径下有效。

②session:
Flask中的session是通过from flask import session。然后添加值key和value进去即可。并且，Flask中的session机制是将session信息加密，然后存储在cookie中。专业术语叫做client side session。

第五章、JWT认证机制

5.1、了解 Session 认证的局限性

Session 认证机制需要配合Cookie才能实现。由于Cookie 默认不支持跨域访问，所以，当涉及到前端跨域请求后端接口的时候，需要做很多额外的配置，才能实现跨域Session认证。

注意：

①当前端请求后端接口不存在跨域问题的时候，推荐使用Session身份认证机制。

②当前端需要跨域请求后端接口的时候，不推荐使用Session身份认证机制，推荐使用JWT认证机制。

5.2、什么是JWT

JWT（英文全称：JSON Web Token）是目前最流行的跨域认证解决方案。

5.3、JWT工作原理

当客户端再次发起请求时，通过请求头的Authorization字段，将Token发送给服务器

用户的信息通过Token字符串的形式，保存在客户端浏览器中。服务器通过还原Token字符串的形式来认证用户的身份。

5.4、JWT的组成部分

JWT 通常由三部分组成，分别是Header（头部）、Payload（有效荷载）、Signature（签名）

三者之间使用英文.分隔，

Header.Payload.Signature

Payload部分才是真正的用户信息，它是用户信息经过加密之后生成的字符串。

Header 和Signature是安全性相关的部分，只是为了保证 Token的安全性。

5.5、JWT的使用方式

客户端收到服务器返回的JWT之后，通常会将它储存在localStorage 或sessionStorage中。

此后，客户端每次与服务器通信，都要带上这个JWT的字符串，从而进行身份认证。推荐的做法是把JWT放在HTTP请求头的Authorization字段中，格式如下：

Authorization:Bearer<token>

5.6、在Express中使用JWT

1)、安装JWT相关的包

运行如下命令，安装如下两个JWT相关的包：

npm install jsonwebtoken express-jwt

jsonwebtoken：用于生成JWT字符串

express-jwt：用于将JWT 字符串解析还原成JSON对象

2）、导入JWT包

const jwt = require('jsonwebtoken')  //用于生成JWT字符串
const expressJWT = require('express-jwt')  //用于将JWT字符串解析还原成JSON对象

3)、secret秘钥

为了保证JWT字符串的安全性，防止JWT字符串在网络传输过程中被别人破解，我们需要专门定义一个用于加密和解密的secret密钥：

①当生成JWT字符串的时候，需要使用 secret密钥对用户的信息进行加密，最终得到加密好的JWT字符串

②当把JWT字符串解析还原成JSON 对象的时候，需要使用 secret 密钥进行解密

const secretKey = 'itwl ^_^'   //secret秘钥本质是字符串

4)、在登录成功后生成JWT字符串

调用jsonwebtoken包提供的sign()方法，将用户的信息加密成JWT字符串，响应给客户端：

参数1：用户的信息对象

参数2：加密的秘钥

参数3：配置对象，可以配置当前token的有效期

不要把密码加密到tooken字符串中

//定义秘钥
const secretKey = 'itwl'
//登录接口
app.post('/api/login',function(req,res)=>{
  res.send({
    status:200,
    message:'登录成功',
    token:jwt.sign({username:userinfo.username},secretKey,{expiresIn:'30s'})  //tocken有效期30s
  })
})

5)、将JWT字符串还原为JSON对象

客户端每次在访问那些有权限接口的时候，都需要主动通过请求头中的Authorization字段，将Token字符串发送到服务器进行身份认证。

此时，服务器可以通过express-jwt这个中间件，自动将客户端发送过来的Token 解析还原成JSON对象：

app.use(expressJWT({secret:secretKey}).unless({path:[/^\/api\//]}))

6)、使用req.user 获取用户信息

当express-jwt这个中间件配置成功之后，即可在那些有权限的接口中，使用req，user对象，来访问从JWT字符串中解析出来的用户信息了，示例代码如下：

req.user

7)、捕获解析JWT失败后产生的错误

当使用express-jwt解析Token字符串时，如果客户端发送过来的Token字符串过期或不合法，会产生一个解析失败的错误，影响项目的正常运行。我们可以通过Express的错误中间件，捕获这个错误并进行相关的处理

//错误处理中间件
app.use(function (err,req,res,next) {
  if(err.name === 'UnauthorizeError'){
    return res.send({
      status: 401,
      message:'无效的token'
    })
  }
  res.send({
    status:500,
    msg:'未知错误',
  })
})

第六章、oAuth2.0协议

是Spring Cloud Gateway集成OAuth2.0后的接口访问流程

认证服务器发回的HTTP回复，包括

access_token	表示访问令牌，必选项。
token_type	表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in	表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token	表示更新令牌，用来获取下一次的访问令牌，可选项。
scope	表示权限范围，如果与客户端申请的范围一致，此项可省略。

oAuth授权方式

四种授权方式

授权码	正宗的OAuth认证，推荐
密码模式	为遗留项目设计
简化模式	为Web 浏览器设计
客户端模式	为后台API服务消费者设计

1）

字段	描述
response_type	必须，固定为code，表示这是一个授权码请求。
client_id	在授权服务器注册应用后得到的唯一标识
redirect_uri	可选，通过客户端注册的重定向URI（一般要求且与注册时一致）。
scope	可选，请求资源范围，多个空格隔开。
state	可选（推荐），如果存在，原样返回给客户端。

前端访问后端服务
1、获取access_token
前端代码

$.ajax({
	url: 'http://localhost:6000/oauth/token' //实际使用请改成服务端真实接口
	,xhrFields: {
	    withCredentials: true
	}
	,data: {'grant_type' : 'password', 'username' : 'admin', 'password' : 'admin'}
	,type: 'POST'
	,beforeSend: function(xhr) {
	  xhr.setRequestHeader('Authorization', 'Basic ' + window.btoa('webApp' + ':' + 'wongoing_web'));
	}
	,success: function(res) {
		if (res && res.data) {
			console.log(res.data.access_token);		//输出获取到的access_token
		}
	}
});

2、携带access_token
后端代码

/**
 * @description: 用户控制器类
 * @author: zheng
 * @date: Created in 2021/2/3 15:58
 * @version: 0.0.1
 * @modified By:
 */
@Api(tags = "用户模块api")
@Slf4j
@RestController
public class SysUserController {
    @ApiOperation(value = "新增或更新用户")
    @CacheEvict(value = "user", key = "#sysUser.username")
    @AuditLog(operation = "'新增或更新用户：' + #sysUser.username")
    @PostMapping("/users/saveOrUpdate")
    public CompletableFuture<Result> saveOrUpdate(@RequestBody SysUser sysUser) throws Exception {
        return CompletableFuture.supplyAsync(()->{
            try {
                return this.service.saveOrUpdateUser(sysUser);
            } catch (Exception ex) {
                log.error("user-saveOrUpdate-error", ex);
                return Result.failed("新增或更新用户失败：" + ex.getMessage());
            }
        });
    }
}