SpringSecurity + JWT实战（前后端分离）

最新推荐文章于 2024-10-08 18:33:57 发布

Liij

最新推荐文章于 2024-10-08 18:33:57 发布

阅读量3k

点赞数 49

分类专栏： SpringSecurity 文章标签： Security JWT Spring

本文链接：https://blog.youkuaiyun.com/As_Yua/article/details/140934005

版权

1. 聊聊SpringSecurity+JWT

1. 聊聊SpringSecurity+JWT

先来聊一聊什么是SpringSecurity ，在上一篇文章中SpringSecurity已经聊过了，大家可以去看看接下来我们聊聊什么是JWT

Json web token (JWT)，是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。官网: JSON Web Token Introduction - jwt.io

2. 前后端完全分离认证问题

互联网服务离不开用户认证。一般流程是下面这样：

用户向服务器发送用户名和密码。
服务器验证通过后，在当前对话(session)里面保存相关数据，比如用户角色、登录时间等等。
服务器向用户返回一个session_id，写入用户的Cookie。
用户随后的每一次请求，都会通过Cookie，将session_id传回服务器。
服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性(scaling)不好。单机当然没有问题,如果是服务器集群，或者是前后端分离的服务导向架构，就要求session 数据共享，每台服务器都能够读取session,。

举例来说，A网站和B网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现? 一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大[]。另外，持久层万一挂了，就会单点失败。另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器，而JWT就是这种方案的一个代表。