我正在阅读Auth0网站上有关Refresh Tokens and SPA的文档,他们声明SPA's should not use Refresh Tokens因为无法安全地存储在浏览器中,而是使用静默身份验证来检索新的访问令牌。
单页应用程序(通常实现隐式授权)在任何情况下都不应获得刷新令牌。原因是这条信息的敏感性。您可以将其视为用户凭据,因为刷新令牌允许用户基本上永远保持身份验证。因此,您无法在浏览器中获取此信息,必须将其安全存储。
我很困惑。根据我的理解,检索新访问令牌的唯一方法是向Auth服务器提交新请求,以及某种形式的Auth0会话cookie来验证登录的用户。收到会话cookie后,Auth0然后,服务器可以发出新的访问令牌。
但是,与浏览器或本地存储中的刷新令牌有什么不同?是什么让Session Cookie比Refresh Token更安全?为什么在SPA中使用刷新令牌是一件坏事?
答案 0 :(得分:4)
关于cookie和刷新令牌以及OAuth2都有很多误解。
首先,只有机密客户端可以使用刷新令牌是不正确的。 OAuth2协议说,机密客户端必须进行身份验证,但不需要机密客户端。因此,客户端身份验证在刷新操作中是可选的。参见RFC 6749, Section 6, Refreshing An Access Token。
第二,您必须了解替代方法:
世界上每个不使用刷新令牌的人都使用选项#3。通过cookie进行的身份验证在功能和安全方面均等同于存储刷新令牌,而且100%。当然,对于令牌和cookie,都有它们保存位置的选项:
a。仅HTTP, b。安全(需要TLS / SSL)和 C。会话(在内存中)与持久性(本地,域存储)
“仅HTTP”选项仅适用于cookie,因此可能代表使用cookie而非令牌的唯一优势。即令牌是通过Javascript处理的,因此无法选择使其远离脚本。也就是说,令牌仅可从存储Javascript的页面域中(或在CORS策略允许的情况下)用于Javascript。因此,这个问题可能被夸大了。
当然,必须注意 始终 使用TLS / SSL传输身份验证Cookie或令牌。坦白地说,由于我们知道大多数违规行为都是在私有公司网络内部发生的,因此端到端TLS不再是基本要求。
最后,是否永久保留cookie或令牌(即存储在可以关闭浏览器甚至重启设备的地方)取决于您在可用性和安全性之间做出的权衡-< em> 您的应用。
对于需要更高安全性的应用程序,只需将所有内容保存在内存中(即会话cookie,Javascript变量中的令牌)。但是,对于不需要那么多安全性并且确实希望会话持续数天或数周的应用程序,则需要存储它们。无论哪种方式,该存储空间都只能由原始域中的页面和脚本访问,因此cookie和令牌在功能上是等效的。
答案 1 :(得分:3)
在SPA中不使用刷新令牌,因为为了使用它 - 并从/token
获取新的访问令牌,SPA需要具有客户端密钥,该密钥无法安全地存储在浏览器。但由于OAuth 2.0 for Native Apps RFC建议/token
端点(对于公共客户端)不需要客户端密钥,因此即使在SPA中也可以使用刷新令牌。
要获取刷新令牌,您需要使用Auth code grant,它将重定向URL中的代码传递给托管SPA的服务器(可能是一个额外的攻击点)。隐式授权仅将令牌传递给浏览器(重定向URL的哈希部分不会到达服务器)。
使用刷新令牌和SSO会话cookie之间的区别 - cookie可能更安全,因为它可以标记为HttpOnly,因此无法使用JavaScript代码进行攻击。
答案 2 :(得分:2)
好问题 - 因此,没有真正安全的方式在浏览器上存储任何令牌(或任何其他机密信息) - 请参阅links such as this。因此,单页应用程序(SPA)不应存储刷新令牌 - 刷新令牌特别成问题,因为它是长期存在的(长期过期或没有过期),如果被盗,则攻击者可以在每次单独到期后继续刷新访问令牌。
最好只在需要时检索访问令牌(例如调用API),并且只存储在内存中(仍然容易受到XSS / CSRF攻击)但更好 - 或者使用和忘记。然后在下次需要访问令牌时再进行一次checkSession调用。
对于您的问题 - checkSession 请求不需要发送令牌。顾名思义就是字面意思 - 针对授权服务器的“检查会话”,以查看会话是否存在。如果是,则授权服务器响应将包含新的访问令牌。见here for an example usage with SPA
如果有任何需要更多说明等,请随时在此回答下留下评论。
答案 3 :(得分:2)
这不再是事实(2021 年 4 月),Auth0 site 现在陈述了不同的内容:
<块引用>Auth0 建议使用刷新令牌轮换,它提供了一种在 SPA 中使用刷新令牌的安全方法,同时为最终用户提供对资源的无缝访问,而不会因 ITP 等浏览器隐私技术而导致 UX 中断。 \
<块引用>Auth0 之前的指导是将带有代码交换证明密钥 (PKCE) 的授权代码流与 SPA 中的静默身份验证结合使用。这是一种比隐式流程更安全的解决方案,但不如具有代码交换证明密钥 (PKCE) 和刷新令牌轮换的授权代码流程安全。
请注意在刷新令牌中启用轮换的重要性。