JWT解决跨域问题详解

介绍

在前后端不分离时，我们利用前面讲过的Spring Security的各种知识点，就可以实现对项目的权限管控。但是在前后端分离时，尤其是在引入了Spring Security后的前后端分离时，我们从前端发来的请求，就会存在一些问题。这些问题就是跨域而导致的问题！

跨域问题的产生，源自浏览器的一个同源策略。

同源策略

是由 Netscape 提出的一个著名的安全策略，它是浏览器最核心也是最基本的安全功能，所有支持 JavaScript 的浏览器都会使用这个策略。在同源策略中，要求 域名、协议、端口 3部分都要相同。

举例来说，http://www.yiyige.com:80/dir/syc.html这个网址，http是协议，www.yiyige.com是域名，80是端口号(80端口号默认可以省略)。同源策略具体规则如下表：

也就是说如果域名、协议、端口号三者之间，只要有一个不同，就认为不是一个网站，也就可能会存在跨域问题。

Claims

"Claims" 是 JSON Web Tokens (JWT) 中的一个重要概念。一个JWT通常包含一组声明（claims），这些声明是关于实体（通常是用户）和其他数据的声明性语句。Claims提供了关于JWT中包含的信息的有关信息。

Claims是关于实体（通常是用户）和其他实体（例如角色或权限）的声明的集合。每个声明都是一个键值对，其中键是声明的名称，值是与该声明相关的信息。例如，一个声明可以是用户的角色，另一个声明可以是用户的电子邮件地址。

Claims中的信息通常被编码为JSON对象，并包含在JWT的负载部分。这些声明提供了关于令牌的有关信息，例如用户身份、角色、权限以及其他相关信息。当验证JWT时，你可以检查这些声明以确保令牌是有效的，并根据需要使用它们来实现身份验证和授权逻辑。

在Java中，我们可以使用第三方库，如"jjwt"来创建和解析JWT令牌，其中包含了Claims

JWT

JWT的结构

我们看JWT是由三部分组成的，大致分为x,y,z

• 第一部分(x)：表示header，标头
• 第二部分(y)：表示payload，负载
• 第三部分(z)：表示signature，签名

所以token的结构式标头.负载.签名

header 标头

标头通常由两部分组成，令牌的类型(JWT)和所使用的签名算法(RSA、SHA)，

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

Payload 负载

令牌的第二部分是有效负载，其中包含声明，声明是有关实体（通常使用户或者其他实体的声明）

{
    "name":"zhangsan",
    "sub":"123456789",
    "admin":"true"
}

Signature 签名

        前面两部分都是使用Base64进行编码的，及前端可以被解开token里的信息，Signature需要使用编码后的header和payload以及我们提供的一个密钥，然后使用header所声明的签名算法进行签名。作用是保证JWT没被篡改。

封装工具类

使用JWT时，需要频繁进行JWT的生成、验证和可能的续签操作。为了提高代码的可维护性和重用性，通常建议创建一个封装JWT操作的工具类或库

这种封装可以提高代码的可读性和可维护性，同时也可以确保在整个应用程序中一致地处理JWT操作，减少错误和安全漏洞的风险。这个工具类可以根据你的具体应用需求来设计和实现，并可以与你的认证和授权逻辑集成在一起。

拦截器

在真正的开发中。因为，每次登录访问资源都要去校验Token。所以，如果在单体架构中，我们可以使用拦截器去操作，