Oauth2认证部署选型：Angular前端还是Spring Boot后端？

我们团队在基于第三方身份提供商的OAuth2认证部署位置上存在分歧，纠结是在Angular前端实现全流程认证，还是通过后端增设代理层完成认证后，携带Bearer Token转发请求至实际REST API。调研后初步认为，访问令牌在后端生成并存储的模式安全性更优，下面针对两个方案的细节及疑问逐一分析：

方案1：后端侧OAuth2认证 #

方案核心 #

在代理服务器生成访问令牌，通过令牌存储机制将其与成功登录的用户ID关联；初期可利用Spring内置功能，通过内存会话存储映射用户会话与访问令牌，自动处理令牌过期逻辑。

疑问解答：仅传递含用户ID的Cookie是否存在安全漏洞？ #

• 核心安全保障：只要Cookie配置正确（启用HttpOnly、Secure属性，设置SameSite=Strict或Lax），能有效防范XSS攻击窃取Cookie内容；
• CSRF风险可控：后端代理层可结合CSRF令牌校验——在前端页面嵌入CSRF token，请求时携带该token，后端验证token与会话的一致性，再配合SameSite属性限制跨域Cookie发送，能大幅降低CSRF风险；
• 令牌泄露风险极低：访问令牌完全存储在后端，前端无法直接接触，从根源上避免了令牌被前端XSS攻击窃取的可能；
• 潜在优化点：内存会话存储仅适合初期测试，生产环境建议改用Redis等分布式会话存储，避免服务重启导致会话丢失，同时支持集群部署。

方案2：Angular前端侧OAuth2认证 #

方案核心 #

前端基于Auth Code Grant类型+PKCE完成全流程OAuth2认证，身份提供商返回的访问令牌存储在前端Cookie中，后续请求直接携带该令牌，可实现无状态模式，实现复杂度低于方案1。

疑问解答：该方案是否存在安全漏洞？方案1是否也有CSRF风险？ #

• 方案2的安全漏洞分析：
  • 若Cookie未配置HttpOnly，访问令牌会暴露给前端JS，存在被XSS攻击窃取的风险；即使启用HttpOnly，若SameSite设置不当，仍可能遭遇CSRF攻击——攻击者诱导用户点击恶意链接，浏览器会自动携带Cookie发送请求，若后端未做CSRF校验，攻击者可直接用令牌执行未授权操作；
  • 对比本地存储：将令牌存在带HttpOnly的Cookie中，比存在本地存储更安全（本地存储易被XSS窃取），但CSRF风险需要额外通过CSRF令牌校验来防范；
• 方案1的CSRF风险说明：
  方案1中前端仅携带含用户ID的Cookie，后端代理层会基于会话验证用户身份，且访问令牌完全由后端管理。只要做好SameSite配置+CSRF令牌校验，CSRF风险是可控的，且远低于方案2——即使攻击者通过CSRF拿到用户ID的Cookie，也无法直接获取访问令牌，必须通过后端代理的合法会话验证才能发起有效请求。

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