图解Jwt和shiro认证方式的区别

1、Jwt的认证方式

用户进行登录中，访问微服务中Controller层的登录方法，若认证通过，生成Token（包含用户数据和权限），返回token信息到前端浏览器，然后，前端那边的代码会记录token，使得再去访问微服务的方法时，请求头都会包含token，然后，后端会解析token，校验token和操作权限，值得注意的是整个过程都不记录用户的任何数据，是一个无状态的服务！

2、shiro的认证方式

用户登录后，交给后端自定义的Realm域，进行用户名和密码的认证比较，认证通过会产生一个以SessionId为key的用户安全数据，然后交给shiro的会话管理，将SessionId存入Redis服务，并将SessionId返回到前端，如果再访问其他后端的控制层方法时，请求头就会包含sessionId，然后再交给后端自定义的Realm域获取安全信息，再交给会话管理将传递过来SessionId与redis服务进行比较，返回自己构造的安全数据（安全数据一定要包含权限信息），因为需要对用户权限进行验证，如果访问请求没有携带sessionId，那么会产生一个新的sessionId，但还需要用户登录，而且，是一个有状态的服务！

建议：关于什么是无状态的服务和有状态的服务可以看看这篇文章

3、为什么用了jwt，还用shiro？或者说用了shiro，为什么还用jwt？

使用JWT和Shiro并不是互斥的选择，它们在权限管理和认证领域各有侧重，结合起来可以发挥各自的优势，满足更复杂的安全需求。

为什么用了JWT，还用Shiro？

1. 互补功能：JWT提供了一种安全的、无状态的认证方式，但本身不包含授权逻辑、会话管理之外的高级安全特性。Shiro则是一个全面的安全框架，除了认证外，还提供了授权、会话管理、加密等安全功能。结合JWT，Shiro可以利用JWT进行认证，同时利用其自身的强大功能来处理授权、会话策略等。

2. 简化实现：虽然可以直接使用JWT进行认证，但实现诸如权限控制、会话过期、记住我等功能时，需要开发者从头开始编码。Shiro通过其丰富的API和预设的组件，可以简化这些功能的实现过程。

3. 统一安全模型：Shiro提供了一套统一的安全模型，使得开发者可以以一致的方式处理各种安全相关的问题，而不仅仅是JWT的认证。这有助于维护代码的一致性和可维护性。

为什么用了Shiro，还用JWT？

1. 适应现代架构：在微服务、前后端分离等现代应用架构中，JWT的无状态特性使其成为理想的选择。Shiro虽然支持会话管理，但在分布式环境下维护会话一致性可能变得复杂。使用JWT可以让每个服务独立验证用户，避免了会话共享的问题。

2. 提升性能和可扩展性：JWT的无状态特性减轻了服务器负担，提升了系统的水平扩展能力。在高并发场景下，避免了集中式的会话存储带来的瓶颈。

3. 跨域支持：JWT天然支持跨域认证，对于需要在不同域名或应用程序间共享认证信息的场景，JWT比传统的基于Cookie的会话认证更加便捷。

综上所述，Shiro和JWT结合使用，可以融合JWT的无状态、跨域优势与Shiro的全面安全功能，为现代应用提供既强大又灵活的安全解决方案。