Shiro+JWT超详解

shiro这几篇博客比较好

https://www.jianshu.com/p/6abc22ec3cb8

https://blog.csdn.net/mine_song/article/details/61616259

jwt原理这几篇博客比较好

https://www.jianshu.com/p/e34a579c63a0

https://learnku.com/articles/17883

https://blog.csdn.net/weixin_43409309/article/details/102569913

首先我们来分别看看shiro和jwt的作用：

 

shiro：

 

三个核心组件

Subject, SecurityManager 和 Realms.
①Subject：即“当前操作用户”。但是，在Shiro中，Subject这一概念并不仅仅指人，也可以是第三方进程、后台帐户（Daemon Account）或其他类似事物。它仅仅意味着“当前跟软件交互的东西”。但考虑到大多数目的和用途，你可以把它认为是Shiro的“用户”概念。Subject代表了当前用户的安全操作，SecurityManager则管理所有用户的安全操作。
②SecurityManager：它是Shiro框架的核心，典型的Facade模式，Shiro通过SecurityManager来管理内部组件实例，并通过它来提供安全管理的各种服务。
③Realm： Realm充当了Shiro与应用安全数据间的“桥梁”或者“连接器”。也就是说，当对用户执行认证（登录）和授权（访问控制）验证时，Shiro会从应用配置的Realm中查找用户及其权限信息。

 

登录认证过程简述

①调用subject.login方法进行登录，其会自动委托给securityManager,login方法进行登录;
②securityManager通过 Authenticator(认证器)进行认证
③Authenticator的实现ModularRealmAuthenticaton调用realm从ini配置文件取用户真实的账号和密码，这里使用的是IniRealm ( shiro自带，相当于数据源) ;

④IniRealm先根据token中的账号去ini中找该账号,如果找不到则给ModularRealmAuthenticator返回null ,如果找到则匹配密码，匹配密码成功则认证通过。

 

 

 

 

 

 

 

 

jwt：JSON Web Token，是一种特殊的token，因此我们在来看看Token是干嘛的？

一、Token

                              token 是一串字符串，通常因为作为鉴权凭据，最常用的使用场景是 API 鉴权，用户凭证。

1. API 鉴权
那么 API 用户凭证一般有几种方式呢？我大概整理了如下：

cookie + session：和平常 web 登陆一样的鉴权方式，很常见，不再赘述。客户端和服务器通过sessionID维持会话。

HTTP Basic：将账号和密码拼接然后 base64 编码加到 header 头中。很显然，因为账号和密码几乎是『明文』传输的，而且每次请求都传，安全性可想而知。

HTTP Digest：将账号和密码加上其他一些信息拼接然后取摘要加到 header 头中。这个安全性比上面要好一点，因为如果是取摘要的话，即使信息段被截取，也无法轻易破解出来（当然也是有破解的可能）。

不过其实最大的问题还是：每次请求都要对账号、密码取一次摘要，也就是说每次请求都要有账号和密码，也就是说账号和密码要么缓存一下，要么就每次请求要去用户输一次密码，这样显然不合适。同样，上面的 Basic 也存在这样的问题。

Token：token 通过一次登录验证，得到一个鉴权字符串，然后以后带着这个鉴权字符串进行后续操作，这样就可以解决客户端每次请求不需要带账号密码的问题，每次请求只要带着token即可，而且也不需要反复使用账号和密码。

二 ：Token和cookie + session的区别：

       一、session的状态保持及弊端

                当用户第一次通过浏览器使用用户名和密码访问服务器时，服务器会验证用户数据，验证成功后在服务器端写入session数据，向客户端浏览器返回sessionid，浏览器将sessionid保存在cookie中，当用户再次访问服务器时，会携带sessionid，服务器会拿着sessionid从数据库获取session数据，然后进行用户信息查询，查询到，就会将查询到的用户信息返回，从而实现状态保持。

 

弊端：

1、服务器压力增大

通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。

2、CSRF跨站伪造请求攻击

session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

3、扩展性不强

如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。

        二、token认证机制，其实这是jwt的功能。。。

 

jwt和最早的token的区别是：

WT全称JSON Web Token，由三部分组成: header(头)、payload(载体)、signature(签名)。 随着技术的发展，分布式web应用的普及，通过session管理用户登录状态成本越来越高，因此慢慢发展成为token的方式做登录身份校验，然后通过token去取redis中的缓存的用户信息，随着之后jwt的出现，校验方式更加简单便捷化，无需通过redis缓存，而是直接根据token取出保存的用户信息，以及对token可用性校验，单点登录更为简单。

 

             token与session的不同主要在：：

①认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）

②浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）

③再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。

 

Token 的种类
一般来说 token 主要三种：

          自定义的 token：开发者根据业务逻辑自定义的 token
          JWT：JSON Web Token，定义在 RFC 7519 中的一种 token 规范
          Oauth2.0：定义在 RFC 6750 中的一种授权规范，但这其实并不是一种 token，只是其中也有用到 token

接下来主要讲解JWT:  这是一个真实的jwt字符串

header={typ=JWT, alg=HS512},body={sub=7, iat=1620354034, exp=1620958834},signature=JAiLPfYv4cetlP1AX678ERwf4aPTUhEXONP9LhWTJrxjdB2PgcJvSVgIV4oXC0Cb7Ivb-_EPcet-C-NU3VJvnQ