Laravel怎么实现单点登录_Laravel怎么处理多端认证【源码】

Lara vel 单点登录与多端认证同步登出的实现关键

在 Lara vel 项目中，一个常见的困惑是：为什么调用 Auth::logout() 后，用户在其他设备上依然保持登录状态？问题的核心在于，默认的登出操作只作用于当前会话。无论是使用 Sanctum、Passport 还是传统的 Session 驱动，要实现真正的“一处登出，处处失效”，都需要开发者主动介入，管理跨设备的状态一致性。

Lara vel的Auth::logout()只清除当前会话，不删除其他设备的token或session；要实现多端同步登出，需手动删除personal_access_tokens（Sanctum）或access_token+refresh_token（Passport），或引入session_version等状态标记进行校验。

为什么 Lara vel 的 Auth::logout() 不会踢掉其他设备？

答案其实很直接：框架的默认设计就是如此。Auth::logout() 的职责仅仅是清除当前请求所绑定的会话数据，它并不会、也无法主动去追踪和清理数据库里该用户在其他设备上遗留的令牌（Token）或会话（Session）记录。

这就导致了一个典型的“错误”现象：用户在电脑端点击退出登录后，用手机 App 或另一个浏览器访问，API 调用依然畅通无阻。如果去后台数据库查看，会发现 personal_access_tokens 表里那些旧的 token 依然安然无恙，并未过期。

所以，关键在于理解：必须主动失效用户的所有令牌，而不能仅仅依赖会话清除。具体怎么做？

• 如果项目使用的是 Sanctum，需要手动删除 personal_access_tokens 表中对应该用户（tokenable_id 和 tokenable_type）的所有记录。
• 如果使用的是 Passport，则需要调用 $user->tokens()->delete() 来批量清理，而不是只删除当前使用的那个 token。
• 这里有一个重要的技术细节需要注意：删除 token 的操作并不会“实时中断”已经建立的连接。它只是确保下一次请求进行令牌验证时会失败（返回 401 状态码），从而实现登出效果。

Sanctum 实现单点登录：覆盖 createToken() 并清理旧 token

Sanctum 默认的设计是允许一个用户无限制地创建多个 token，这很灵活，但也意味着它本身不具备“单点登录”（即新登录自动使旧登录失效）的能力。要实现这个功能，最直接、副作用也最小的思路是：在为用户颁发新令牌之前，先把他名下所有旧的令牌清理干净。

这个方案特别适用于 App 登录与网页登录共用同一套 Sanctum 令牌体系的场景，要求做到“一处登录，别处失效”。

• 在登录逻辑中，不要直接调用 $user->createToken('api-token')。
• 更安全的做法是，先执行 $user->tokens()->delete() 来删除该用户的全部现有令牌。（当然，如果确定只存在一个当前令牌，用 $user->currentAccessToken()->delete() 也可以）。
• 清理完毕后，再调用 $user->createToken('api-token') 生成全新的令牌。
• 确保你的用户模型已经使用了 HasApiTokens 这个 Trait，它提供了 tokens() 这个关联关系方法。
• 从性能角度看，这只是一次简单的数据库删除操作，几乎不会带来额外的开销，也无需担心 N+1 查询问题。

Passport 单点登录的关键：别漏掉 refresh_token 和 access_token 的级联清理

与 Sanctum 不同，Passport 的令牌机制是成对出现的：一个用于短期授权的 access_token，搭配一个用于续签的 refresh_token。这就引出了一个关键问题：如果只删除了 access_token，用户仍然可以凭借有效的 refresh_token 去换取新的 access_token，登出操作也就功亏一篑。

一个典型的疏漏场景是：开发者调用了 $user->tokens()->delete() 后，发现前端依然能用旧的 refresh_token 访问 /oauth/token 接口，并成功拿到新的访问令牌。

• 问题的根源在于，Passport 模型上的 tokens() 关系默认只关联到 oauth_access_tokens 表，删除操作不会自动级联到 oauth_refresh_tokens 表。
• 因此，必须手动清理 refresh token。可以通过 DB::table('oauth_refresh_tokens')->where('access_token_id', $tokenId)->delete() 来删除特定的，或者更稳妥地，直接按 user_id 进行批量删除。
• 推荐的做法是，在删除 access token 时，通过关联加载其对应的 refresh token 一并删除，或者执行跨表的联合删除操作（需注意数据库的外键约束设置）。
• 兼容性提示：在 Lara vel 10+ 和 Passport 11+ 版本中，refresh_token 的表结构可能有所调整，但核心逻辑——需要同时清理两种令牌——是始终不变的。

Session 驱动下怎么让多端登出同步？别只信 Session::flush()

对于使用传统 Session 驱动（如 file, redis）的 Web 应用，Session::flush() 或 Auth::logout() 同样只清除当前请求对应的 session 数据。存储在 Redis 或文件系统中的其他会话记录依然有效。要实现跨设备踢出，必须从状态存储层想办法。

设想这样一个场景：用户在电脑端点击“退出登录”，期望手机上的网页会话也能立刻失效。

• 一种原始的思路是，当 Session 存储在 Redis 时，尝试用 Redis::keys("lara vel_session*") 扫描所有会话键，然后匹配其中存储的 user_id 进行删除。但这并不推荐，因为性能差，且依赖 Session 数据结构，不可靠。
• 更稳健的方案是引入一个全局版本标记。例如，在用户表中增加一个 session_version 或 last_logout_at 字段。用户每次登录时，生成一个唯一版本号（如 UUID）存入该字段和当前 Session。之后，通过一个全局中间件，在每次请求前比对 Session 中的版本号与数据库中的是否一致。若不一致，则强制登出。
• 另一个等效的实现是使用缓存标记：登录时，执行 Cache::put("user:{$id}:session_version", $uuid, 3600)；登出时，执行 Cache::forget(...) 使该缓存失效。所有设备在验证会话时，都需要检查缓存中的版本号是否匹配。
• 这里的核心要点是：Session 驱动本身是无状态或分散状态的。要实现单点登录，就必须引入一个中心化的、共享的状态存储机制来协调所有设备，否则纯靠 Session 驱动本身是无法做到的。

说到底，技术实现本身并不复杂。真正的挑战往往在于业务逻辑的定义：你所谓的“同一个用户”到底指什么？是按 user_id 一刀切，还是要结合 device_id 区分设备？是否需要支持“保留当前设备，只踢出其他设备”这种更细粒度的控制？这些业务规则，需要开发者自己来设计和兜底，框架不会、也不应该替你做决定。