共计 982 个字符，预计需要花费 3 分钟才能阅读完成。
单页面利用 (Single Page Application) 通过 API 调用同外界交互。调用 API 时咱们通常须要在申请中附加拜访令牌，即 Access Token. SPA 开发人员须要确保令牌和其余敏感数据不易受到跨站点脚本 (XSS) 的攻打，并且不会被歹意 JavaScript 读取。
Auth0 SDK 倡议将令牌存储在浏览器内存中作为最平安的选项。应用 Web Worker 解决令牌的传输和存储是爱护令牌的最佳形式，因为 Web Worker 运行在与应用程序的其余部分不同的全局范畴内。应用 Auth0 SPA SDK，其默认存储选项是利用 Web Workers 的内存存储。
如果因为某种原因不能应用 Web Workers，Auth0 倡议应用 JavaScript 闭包来模仿公有办法。
应用默认存储选项为内存存储的 Auth0 SPA SDK，依据令牌的类型利用 Web Workers 和 JavaScript 闭包。
留神：采取这种形式存储的 Access Token 不提供跨页面刷新和浏览器选项卡的持久性。
Browser local storage scenarios
应用浏览器本地存储能够代替须要从 iframe 检索拜访令牌和跨域基于 cookie 的身份验证的机制，因为这些机制因为浏览器限度（例如 ITP2）而无奈实现。
将令牌存储在浏览器本地存储中提供了跨页面刷新和浏览器选项卡的持久性，然而如果攻击者能够应用跨站点脚本 (XSS) 攻打在 SPA 中运行 JavaScript，他们能够检索存储在本地存储中的令牌。导致 XSS 攻打胜利的破绽可能位于 SPA 源代码中，也可能位于 SPA 中蕴含的任何第三方 JavaScript 代码（例如 bootstrap、jQuery 或 Google Analytics）中。
如果 SPA 应用隐式（业界标准是倡议应用带有 PKCE 的受权代码流）或混合流，为了升高平安危险，能够缩小令牌的到期工夫。这缩小了反射 XSS 攻打的影响。要缩小过期工夫，能够在 Dashboard > API > 设置里批改浏览器流的令牌过期，单位为秒。
将来自域外源的第三方 JavaScript 代码的数量缩小到所需的最低限度（例如指向 jQuery、Bootstrap、Google Analytics 等的链接）。缩小第三方 JS 代码可升高 XSS 破绽的可能性。在第三方脚本中执行子资源完整性 (SRI) 查看以验证获取的资源是否在没有意外操作的状况下也可能平安地交付。
