在Laravel中如何通过JWT认证保护供SPA及移动应用调用的Web路由

1. 基础JWT配置规范 #

• 加密算法选择：项目规模小、内部使用优先选HS256对称加密，多团队协作、安全要求高的场景优先选RS256非对称加密，降低密钥泄露风险
• 双Token机制配置：设置两类Token，短有效期的access_token建议15_{30分钟，长有效期的`refresh_token`建议7}30天，移动端可适当延长到90天支持静默刷新，避免用户频繁登录
• Payload字段规范：不要存放密码、身份证号等敏感信息，仅写入用户ID、用户角色、签发时间、过期时间等非敏感必要信息即可

2. 不同端的Token传递逻辑 #

2.1 SPA端处理方案 #

• 若SPA和API同域名部署，不要将JWT存放在localStorage中（易被XSS攻击窃取），推荐存放在带有HttpOnly、Secure、SameSite=Strict属性的Cookie中，请求时浏览器会自动携带，无需前端手动处理请求头
• 若SPA和API跨域部署无法使用Cookie，将access_token存放在前端内存中（如Vue的Pinia、React的Context），refresh_token仍存放在HttpOnly Cookie中，请求时手动在请求头添加Authorization: Bearer <access_token>即可

2.2 移动端处理方案 #

• 移动端不存在同源限制，将access_token和refresh_token都存放在系统自带的安全存储区域，比如iOS的Keychain、Android的Keystore，不要存放在普通沙盒文件或本地缓存中
• 所有请求都手动在请求头携带Authorization: Bearer <access_token>即可

3. 路由拦截校验逻辑 #

• 所有需要鉴权的路由统一添加全局校验中间件，首先从请求头或Cookie中提取JWT
• 第一步校验JWT签名是否合法，签名无效直接返回401未授权
• 第二步校验Token有效期，若access_token过期，返回401的同时附带刷新标识，引导客户端使用refresh_token调用刷新接口换取新的access_token，若refresh_token也过期则直接返回登录提示
• 第三步若路由有角色权限限制，额外校验Payload中的用户角色是否匹配访问要求，不匹配直接返回403禁止访问

4. 额外安全加固建议 #

• 服务端维护活跃refresh_token列表，用户主动退出登录时将对应refresh_token加入黑名单，避免未过期的Token被恶意使用
• 所有接口开启限流策略，防止JWT被暴力破解
• 生产环境必须开启HTTPS传输，避免Token在传输过程中被抓包窃取

注意：JWT签发后无法篡改内容，仅能通过过期/拉黑方式失效，若需要修改用户权限等信息，需要让旧Token失效后重新给客户端签发新Token

内容的提问来源于stack exchange，提问作者Emfor Projects