登录态

登录态验证

最基本的鉴权

有两种方案：基于session 或 基于token

基于会话也就是session的 用户登录后会将一些信息存在后端 或者是转存到redis里面 利用redis可以共享这个登录态 比如同一公司下的两个网站 同一个用户登入网站1 redis中记录了登录态 如果再去网站2 是无需再登录的 可以共享这个session 但是这样的缺陷是 后端需要存储维护session 要么是在本地要么是在微服务 如果用户量很大 或者并发量很大 无疑会给后端带来很大压力 而且好像还有一个问题 如果用户退出浏览器重新打开网页的化 貌似是不能维持登录态的 需要重新登录 应该是浏览器本地没有存储登录信息 全依赖于后端存储的session 如果要维持登录态 需要结合cookie来存储SessionId

而jwt是提供token 让用户（客户端）存储 后端不再维护会话 只需借助签名算法验证 JWT 是否被篡改即可

基于 Session 的鉴权

认证过程：

用户登录后，后端会生成一个 SessionID 并将用户的登录信息（如用户 ID 或权限信息）存储在后端（通常是内存或 Redis 中）。

浏览器通过 HTTP Cookie 保存 SessionID，后续每次请求时都携带这个 SessionID，后端通过匹配 SessionID 来验证用户的登录态。

优点：

Redis 支持会话共享：

    比如在同一公司下的多个网站，同一个用户登录 Site 1 后，后台将会话信息存储在

Redis 中，共享同一份 Session 数据，用户访问 Site 2 时无需重新登录。

易于实现：

    传统 Web 应用程序（如 JSP、Servlet）普遍采用这种方式，现成框架支持较多。

缺点：

需要后端存储 Session 状态：

    后端需要利用 Redis 或内存来存储并维护所有用户的会话信息。当用户量或并发量较大时，可能会对

Redis 或后端内存造成压力。

浏览器重启后会话丢失问题：

    如果没有结合 Cookie 在客户端存储 SessionID，用户关闭浏览器会导致会话丢失，后续无法自动恢复登录态。

不适合分布式架构：

    如果后端是分布式服务，通常需要额外的集中式存储（如 Redis）来管理共享的会话数据，增加了实现复杂度。

改进点：

结合 Cookie 存储 SessionID：

    设置 Cookie 的有效期，使登录态可以长时间保留。例如，即使用户关闭浏览器，仍能通过

Cookie 找回登录状态。

增加分布式 Session 支持：

    借助 Redis 做集中式会话存储或采用 Spring Session（支持多实例）等方案来管理会话数据。

基于 Token（JWT）的鉴权

认证过程：

用户登录后，后端生成一个 JWT（JSON Web Token），将用户的身份信息（如用户 ID、角色等）编码进 JWT，并使用签名算法生成 Token 返回给前端。

客户端（浏览器/移动端）保存这个 Token（可以存储在 LocalStorage 或 HttpOnly Cookie 中）。

每次请求时，客户端通过 Authorization: Bearer 将 Token 发送给后端，后端通过验证 Token 的签名和有效性来确定用户身份。

优点：

后端无状态：

    后端无需存储任何会话信息，只需通过 Token 签名验证其真实性和有效性。

支持分布式架构：

    由于后端不需要存储会话状态，Token 适合微服务或跨服务的分布式场景。

跨域支持：

    使用 Authorization Header，与传统基于 Cookie 的 Session

不同，Token 更适合前后端分离和跨域场景。

多终端兼容：

    无论是浏览器、移动端、桌面端还是其他客户端，都可以方便地拿到 Token 后进行统一认证。

缺点：

注销和失效难以实时生效：

    Token 本质上是自包含的，有效期由签名中的 exp 决定。若用户登出后 Token

未到期，则后端无法立即失效 Token。

解决方法：

    引入黑名单，手动阻止某些 Token 的使用（需要额外数据库存储支持）。

安全性问题：

    如果 Token 被恶意用户截获，很难防止滥用。

    客户端自行存储 Token 时，容易因为不安全操作（如存储在 LocalStorage）被窃取。

改进点：

结合 HttpOnly Cookie 存储 Token：

避免 Token 被 JavaScript 直接读取。

短有效期 Token + 刷新机制：

通过短生命周期 Token 配合 Refresh Token 来平衡安全性和用户体验。例如，短时间内重复登录无需重新输入密码，提升用户体验。

image-2e577dbc

Spring Security 的角色

  1. 认证作用：
    • 验证用户身份是否有效，比如登录密码校验、Token 校验（JWT）、第三方登录验证（如 OAuth2）。
  2. 授权作用：
    • 确保不同用户仅能访问其拥有权限的接口或资源。
    • 配合注解实现细粒度的权限控制，比如 @PreAuthorize("hasRole('ADMIN')")。
  3. 保护作用：
    • 防止未授权的访问，如禁止直接请求后端接口。
    • 默认开启常见 Web 安全机制（如 CSRF 防御、CORS 配置等）。
    • 提供灵活的配置项，开发者可以方便地定义哪些接口需要保护，哪些接口需要开放（如 Swagger 文档）。

小结

  1. 基于 Session：
    • 适合传统 Web 应用，有明确的服务端会话状态管理，实时性较强，但需要额外的存储和扩展配置（如 Redis）。
    • 如需维持登录态，需要结合 Cookie 存储 SessionID。
  2. 基于 JWT：
    • 更现代化的无状态认证方式，适合前后端分离、分布式微服务和跨域场景。
    • 后端只负责验证 Token 的正确性（签名和过期时间），无需存储任何会话状态。
  3. Spring Security 的作用：
    • 专注于后端接口保护，防止未经授权访问。可与 Session 或 Token 方案结合

项目分区导航：⬅️ 01-登录鉴权 | 02-登录态 | ➡️ 03-session单模式登录+鉴权流程流程一览