如何在客户端处理访问令牌和刷新令牌

Posted

技术标签:

【中文标题】如何在客户端处理访问令牌和刷新令牌【英文标题】:how to deal with access token and refresh token in client side 【发布时间】:2016-03-22 17:47:33 【问题描述】:

我正在使用 AngularJS 客户端创建一个网站,并在 REST 中与后端(在其他域中)进行通信。

为了验证每个调用,我通过每个 HTTPS 调用的标头传递一个令牌:“Authorization : Bearer access_tokenXXXXXX”

当令牌过期时,我可以通过 refresh_token 创建一个新令牌。

access_token和refresh_token需要保存在客户端,因为浏览器需要在HTTP请求头中设置之前以明文形式保存。

我的问题是:

问题 1:存储 access_token 和 refresh_token 以使其对浏览器可用的推荐方式是什么,这样相对安全? (我有私人照片等敏感数据)

问题 2:access_token 和 refresh_token 的建议生命周期(= 不可用前的时间)是多少? (仅供参考,我在 401 响应后刷新令牌,我的应用是社交应用)

问题 3:我有架构问题吗?我是否应该更改它以便根本不使用令牌的 javascript,并使用 HTTP-ONLY cookie?

谢谢:)

杰弗里

更新:

我最终选择了 HTTP-ONLY cookie。我正在使用 Django Oauth Toolkit,因此 Django 正在等待 HTTP 标头中的授权,而不是 cookie 中的授权。

为了解决这个问题,我使用了一个中间件来收集 cookie 的令牌并将其设置在标头中。它还应该允许我在 access_token 过期之前重新验证用户(使用刷新令牌)。

【问题讨论】:

【参考方案1】:

我认为你问的问题 3 是对的。绝对使用 HTTP-Only cookie,这是最安全的浏览器存储类型。

如 smwikipedia 提供的链接中所述,使用仅 HTTP cookie 有助于防御 XSS。为了防御 CSRF,您应该查看 this AngularJS 机制。

Cookie 的实际格式可以是 JWT 或其他任何格式。

问题 2 的答案实际上取决于您的用户在严格的安全性和便利性之间进行权衡的最佳点。你最了解你的用户,所以这真的是你自己的判断。

【讨论】:

感谢您的回答,我将切换到 HTTP-ONLY cookie。关于 CSRF,我正在使用 Django Rest Framework 和这个模块:github.com/ottoyiu/django-cors-headers,它工作得很好,所以我应该没问题 :) 我假设您的意思是 HTTPS-Only 而不是 HTTP-Only ? HTTP-Only 是在 cookie 上设置的一个标志,它告诉浏览器不要让 JavaScript 访问它,另一个标志 - “SECURE”告诉浏览器不要在不使用 HTTPS 的情况下发送 cookie。因此,您需要在身份验证相关的 cookie 上使用这两个标志【参考方案2】:

我面临着与你类似的问题。

我正在为browser-basednon-browser 客户端开发一个服务层。我打算使用 JWT (JSON Web Token) 对两者进行身份验证。

评论太长,所以我将其发布为答案。

对于问题1,根据here,出于安全考虑,他们建议将JWT令牌存储在cookie中。

对于问题 2,here 是一个关于 JWT 过期处理的线程。

对于问题 3,我还没有评论。

【讨论】:

感谢您的回答,我将使用 HTTP-ONLY 安全 cookie :)(但我不会实现 JWT,这似乎有点矫枉过正)

以上是关于如何在客户端处理访问令牌和刷新令牌的主要内容,如果未能解决你的问题,请参考以下文章

如何保护刷新令牌?

如何在前端和后端存储 JWT 刷新令牌?

如何使用带有 OpenId Connect 的刷新令牌在 asp.net 核心中处理过期的访问令牌

如何在 asp.net 中生成刷新令牌?

Azure:如何获得刷新令牌?当连接的输出仅提供访问令牌时使用 Curl

如何在客户端处理多个请求/API 调用并行的 JWT 刷新令牌?