使用 jwt 进行鉴权, 刷新 token 功能相对于仅仅使用 access-token 在安全上体现在什么方面?

老生常谈的问题了，token 的安全性和它的使用频率负相关，而 access_token 的使用频率非常高，所以如果将 access_token 的有效期延长，会导致泄漏后损失加大，而 refresh_token 的使用频率相对低很多，安全性也要更高，通过引入 refresh_token，能在保证 access_token 泄漏后损失不加大的前提下，延长 token 的有效期。

我设置 8 小时到期，系统使用人员他们 9 点上班。

其实可以想一下为啥要用 token，直接用 username 和 password 还能永久有效呢，使用 access token + refresh token 不过是安全与便捷的一个折中点，对安全的提升肯定是有的

@maichael refresh_token 跟 access_token 一样存储在客户端吗? 在客户端的话 需要考虑 refresh_token 和 access_token 一起泄露吗

@dadovicn #4 refresh_token 和 access_token 一起泄漏，就等同于一个长有效期的 access_token 泄漏，后者怎么处理，前者就怎么处理。

JWT 这种机制安全性并不高，但就是这个并不高的安全性，对一般的应用来说都已经足够了。这个世界上不存在绝对的安全，所以我们在选择安全机制的时候，要充分评估自身的安全需求。一切按需求来就行，没有必要追求更高的安全性。

楼主用的是那个 jwt 包，我用的 Java-jwt 这个包（这个包好像不带刷新 token 过期时间方法），没做刷新机制，设置 12 小时过期，过期给提示从新登录就行了。

Access token 放 header 防止 CSRF, Refresh token 应该是用 httpOnly 的 cookie 来防止 XSS. Jwt 自带鉴权，可以在分布式，微服务里面独立 verify，无需一个 centralized auth 服务。而 refresh token 用来做用户管理，revoke, 禁用用户，权限管理配置等等。

@zhigang1992 移动端 cookie 好处理吗？我们目前也在用 OAuth2 JWT

@Kyle18Tang 没有区别的呀，除非是跨域的时候有些浏览器默认不发 Cookie 。移动端和桌面在这里应该是没有区别的。

@zhigang1992 #10 H5 没问题，我想问的是原生安卓和 iOS 这种 API 能不能支持 Cookie，我们现在做的 refresh_token 不是很好，当时有参考用 Cookie，但是对原生不了解，就没有用。

@Kyle18Tang 原生 App 不怕 CSRF 和 XSS，直接放 Header 里面就好 imo