Rust前后端分离应用（Yew+Actix）API后端认证最优方案咨询

核心思路 #

后端生成签名后的JWT，前端仅读取JWT的公开payload字段做路由跳转校验，后端负责全量的签名验证与权限校验，既满足前端路由控制需求，又无需前后端共享密钥，同时支持第三方消费者调用。

1. 后端（Actix）生成与分发JWT #

• 用户登录时，Actix验证账号密码合法性后，使用后端私钥生成JWT：
  • Payload中仅包含非敏感的公开字段：exp（过期时间）、user_id（用户唯一标识）、roles（权限角色标签）等；
  • 采用非对称加密算法（如RS256），后端用私钥签名，公钥可公开（但前端无需使用）；
  • 将JWT返回给前端，同时生成HttpOnly的Refresh Token存入Cookie（用于后续刷新Access Token）。

2. 前端（Yew）本地路由校验（无需调用后端） #

• 前端将JWT存入localStorage（需配合CSP内容安全策略防范XSS）；
• 实现路由守卫（基于Yew Router的中间件逻辑），在跳转目标路由前执行以下校验：
  • 检查localStorage中是否存在JWT；
  • 解码JWT的Payload（Base64解码即可，无需验证签名），校验exp字段是否未过期；
  • 根据Payload中的roles字段，判断用户是否具备访问目标路由的权限；
  • 若校验不通过，直接跳转至登录页，全程无需调用后端接口。

3. 后端API的全局认证校验 #

• 所有需要授权的Actix接口，统一拦截请求头中的Authorization: Bearer <token>：
  • 用后端私钥验证JWT的签名合法性，确保token未被篡改；
  • 再次校验Payload中的exp过期时间、roles权限等字段；
  • 校验通过则放行请求，否则返回401/403状态码；
  • 第三方消费者调用后端API时，遵循相同流程：先登录获取JWT，再携带token请求，无需额外适配其他认证方案。

4. 优化补充 #

• Token生命周期管理：使用短有效期（如15分钟）的Access Token + 长有效期（如7天）的Refresh Token。Access Token过期后，前端调用后端刷新接口（携带Cookie中的Refresh Token）获取新的Access Token，避免用户频繁登录；
• 安全防护：
  • 前端避免在JWT中存储敏感信息，防止token被窃取后泄露数据；
  • 配置CSP策略限制脚本注入，降低XSS风险；
  • Refresh Token存入HttpOnly、SameSite的Cookie，禁止前端读取，防止XSS窃取。

内容的提问来源于stack exchange，提问作者Mathias Hemmer