在SPA PKCE流程中广播access token的风险程度如何？

Broadcast Channel会不会被窃听？ #

• 首先得明确：Broadcast Channel是受同源策略限制的——只有和你的SPA同域名的页面/脚本才能监听同一名称的通道。如果你的域名下没有混入恶意脚本（比如被注入的第三方恶意代码），完全不用担心外部网站能窃听你的广播消息。
• 但如果你的SPA引入了不可信的第三方脚本（比如来源不明的广告、统计工具），这些脚本在同源环境下可以创建同名的Broadcast Channel来监听消息，这时候授权码就有被窃取的风险。所以核心是管控好你域名下的所有脚本权限。

Refresh Token能不能应对Access Token泄露？ #

• Refresh Token的设计初衷就是用来在Access Token过期或泄露时，生成新的有效Access Token，但这里有几个关键细节要注意：
  • 你的SPA是不可信客户端，绝对不能把Refresh Token存在localStorage/sessionStorage里——这和存Access Token一样容易被窃取。正确做法是用带HttpOnly、Secure、SameSite属性的Cookie存储Refresh Token，让浏览器自动管理，禁止JS访问，从根源降低泄露风险。
  • 如果只是Access Token泄露，攻击者最多能用到它过期为止。但如果Refresh Token也泄露了，攻击者就能持续刷新获取新的Access Token。这时候要启用Refresh Token轮换机制：每次刷新令牌时，返回一个新的Refresh Token，旧的立即失效；同时给Refresh Token设置合理的过期时间，进一步缩小风险窗口。
  • 结合你已经在用的PKCE流程，本身已经能有效防止授权码被拦截，再加上Broadcast Channel的同源限制，只要做好第三方脚本的安全审计，整体风险是可控的。

额外的安全小建议 #

• 给你的Broadcast Channel起一个唯一、难猜的名称，别用auth-channel这种太直白的名字，降低同源内恶意脚本猜中并监听的概率。
• 传递授权码时带上校验用的state：SPA发起认证前生成一个随机state存在本地，iframe回调收到授权码时把这个state一起广播，SPA收到消息后先校验state是否匹配，确保消息来自合法的认证回调。
• 定期检查你引入的第三方脚本，只保留必要的、可信的资源，避免给恶意脚本可乘之机。

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