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?
-
互补功能:JWT提供了一种安全的、无状态的认证方式,但本身不包含授权逻辑、会话管理之外的高级安全特性。Shiro则是一个全面的安全框架,除了认证外,还提供了授权、会话管理、加密等安全功能。结合JWT,Shiro可以利用JWT进行认证,同时利用其自身的强大功能来处理授权、会话策略等。
-
简化实现:虽然可以直接使用JWT进行认证,但实现诸如权限控制、会话过期、记住我等功能时,需要开发者从头开始编码。Shiro通过其丰富的API和预设的组件,可以简化这些功能的实现过程。
-
统一安全模型:Shiro提供了一套统一的安全模型,使得开发者可以以一致的方式处理各种安全相关的问题,而不仅仅是JWT的认证。这有助于维护代码的一致性和可维护性。
为什么用了Shiro,还用JWT?
-
适应现代架构:在微服务、前后端分离等现代应用架构中,JWT的无状态特性使其成为理想的选择。Shiro虽然支持会话管理,但在分布式环境下维护会话一致性可能变得复杂。使用JWT可以让每个服务独立验证用户,避免了会话共享的问题。
-
提升性能和可扩展性:JWT的无状态特性减轻了服务器负担,提升了系统的水平扩展能力。在高并发场景下,避免了集中式的会话存储带来的瓶颈。
-
跨域支持:JWT天然支持跨域认证,对于需要在不同域名或应用程序间共享认证信息的场景,JWT比传统的基于Cookie的会话认证更加便捷。
综上所述,Shiro和JWT结合使用,可以融合JWT的无状态、跨域优势与Shiro的全面安全功能,为现代应用提供既强大又灵活的安全解决方案。