OAuth2+SPA场景下：AccessToken应在客户端还是服务端验证？
嘿，刚接触OAuth2和SPA的话，你的这些困惑真的很典型，我来一步步帮你理清楚：
谁来负责AccessToken的验证？
首先明确核心原则：受保护资源的后端才是验证AccessToken有效性的绝对主体，前端SPA的验证只是辅助性的体验优化，完全不能替代后端的校验。
你的SPA现在做的路由守卫（检查localStorage里有没有token）是合理的——这是用来控制页面跳转逻辑，避免未登录用户直接访问受保护页面，但这不算“验证token是否合法”。因为前端的所有代码和存储的数据都可能被攻击者篡改，比如有人可以伪造一个假token存在localStorage里，前端的检查根本拦不住，只有后端验证才能确保token是授权服务器合法签发的。
SPA需要额外执行验证操作吗？
你可以在前端做一些轻量的校验来提升用户体验，比如：
- 解析JWT的payload（JWT是base64编码的，前端可以直接解码），检查
exp字段（过期时间），如果token已经过期，直接引导用户重新登录 - 检查token的格式是否符合JWT的规范（比如有没有
.分隔的三段结构）
但记住：这些操作只是为了让用户更早感知到登录状态失效，不能作为安全校验的依据。绝对不要依赖前端的验证来决定是否允许访问资源，最终的权限判断必须交给后端。
另外，你不需要专门把token发给后端请求验证，而是在调用受保护资源接口的时候，把token放在Authorization请求头里（格式是Bearer <你的AccessToken>），后端收到请求后会自动完成验证流程。
SSO提供的JWT验证密钥该怎么用？
划重点：这个密钥绝对不能配置到SPA代码里！
SPA的代码是完全暴露给用户的，任何人都能从浏览器的开发者工具里拿到这个密钥，一旦泄露，攻击者就能伪造出授权服务器签发的合法JWT，直接绕过所有权限校验，这是极大的安全风险。
这个密钥的正确用法是：配置在你的受保护资源后端服务器上。后端在收到AccessToken后，用这个密钥来验证JWT的签名，确认这个token确实是你的SSO授权服务器签发的，并且没有被篡改过。
结合你的业务流程总结正确流程
- 用户访问SPA，前端检查localStorage有没有token，没有就引导到登录页
- 用户登录后，授权服务器返回AccessToken，前端把它存在localStorage里
- 用户访问受保护页面时，前端路由守卫检查token存在，允许跳转
- 前端调用后端受保护接口时，在请求头带上
Authorization: Bearer <token> - 后端收到请求后，用SSO提供的密钥验证token的签名、有效期、权限等，验证通过才返回资源
内容的提问来源于stack exchange，提问作者redshift
