OAuth2.0在SPA应用中的安全陷阱
SPA（单页应用）通常采用隐式授权（Implicit Flow）或PKCE（Proof Key for Code Exchange）授权模式，但存在以下安全隐患：
隐式授权模式的漏洞
- 访问令牌直接暴露在URL中，可能被浏览器历史记录或第三方插件截获。
- 缺乏刷新令牌机制，导致长期会话管理困难。
PKCE模式的潜在风险
- 若未正确实现
code_verifier和code_challenge的绑定，可能遭受授权码拦截攻击。 - 前端代码可能被篡改，导致重定向URI被恶意修改。
规避安全陷阱的关键措施
使用PKCE代替隐式授权
- 强制要求SPA应用使用PKCE增强的授权码模式（OAuth2.0 RFC 7636）。
- 示例生成
code_verifier的代码：
function generateCodeVerifier() {const array = new Uint32Array(32);window.crypto.getRandomValues(array);return Array.from(array, dec => ('0' + dec.toString(16)).slice(-2)).join('');
}
严格限制令牌存储方式
- 避免使用
localStorage存储令牌，改用HttpOnly和Secure标记的Cookie。 - 实现短期令牌自动续期机制，减少令牌泄露窗口期。
强化重定向URI验证
- 在服务端完整验证重定向URI，包括协议、域名和路径。
- 禁止使用通配符域名或开放重定向器。
添加安全头部保护
- 部署CSP（内容安全策略）防止XSS攻击：
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
- 启用
X-Frame-Options和Strict-Transport-Security头部。
实施额外防护层
令牌绑定技术
- 将颁发的访问令牌与前端生成的指纹（如浏览器特性）绑定。
- 每次API请求时验证令牌与客户端的匹配性。
实时令牌吊销
- 实现令牌状态检查端点，对异常IP或设备发起的使用请求立即废止令牌。
- 记录令牌使用日志，建立异常行为检测模型。
开发环境特殊处理
- 联调阶段使用
localhost环回地址代替IP直连，避免证书警告导致安全机制失效。 - 为测试环境配置独立的应用注册信息，与生产环境完全隔离。
